P3
There are 375 tests in open/test/ that contain the string @enablePreview. That's a lot of tests (which is good, in its way) but given that many features now go through multiple rounds of preview, it makes it hard to know when the tag should be removed.
Perhaps jtreg should be updated to permit a "reason" to be specified, (or else we could stylistically use a keyword) so that it is easier to locate tests for features that are exiting preview.
Currently, the syntax is
@enablePreview [true|false]
where the optional boolean value allows preview mode to be enabled or disabled.
It is proposed that this should be extended to permit an additional token before the boolean value.
@enablePreview [token] [true|false]
This will make it easier to grep all the tests looking for tests for specific features, so that it is easier to locate instances of `@enablePreview` that should be removed.
Since it is not inconceivable that a test could leverage multiple features, maybe the proposal should be
@enablePreview [tokens] [true|false]
i.e. allow a whitespace-separated list of tokens before the boolean value.
It is further proposed that any such `token` should match a specific regex, to be defined, but which allows forms like NAME-NUMBER or NUMBER, e.g. JEP-467, 8123456
It is _not_ expected that `jtreg` should not validate tokens via any web access.
It might be reasonable/desirable to register the set of allowable tokens in `TEST.ROOT` in a similar fashion to the way that the set of allowable keywords is defined. This would help catch simple typos and any non-approved reasons to use `@enablePreview`. This would also give us a quick and easy way to flag related tests by simply removing the token from the allowable set in TEST.ROOT.
Given there are a large number of tests that currently use `enablePreview`, the tokens in the tag should be optional for now, although eventually they could be mandatory based on the JDK version -- i.e. tests in older versions of the test suite would be allowed to not have any tokens, but tests in newer versions of the test suite would be required to use them.
Perhaps jtreg should be updated to permit a "reason" to be specified, (or else we could stylistically use a keyword) so that it is easier to locate tests for features that are exiting preview.
Currently, the syntax is
@enablePreview [true|false]
where the optional boolean value allows preview mode to be enabled or disabled.
It is proposed that this should be extended to permit an additional token before the boolean value.
@enablePreview [token] [true|false]
This will make it easier to grep all the tests looking for tests for specific features, so that it is easier to locate instances of `@enablePreview` that should be removed.
Since it is not inconceivable that a test could leverage multiple features, maybe the proposal should be
@enablePreview [tokens] [true|false]
i.e. allow a whitespace-separated list of tokens before the boolean value.
It is further proposed that any such `token` should match a specific regex, to be defined, but which allows forms like NAME-NUMBER or NUMBER, e.g. JEP-467, 8123456
It is _not_ expected that `jtreg` should not validate tokens via any web access.
It might be reasonable/desirable to register the set of allowable tokens in `TEST.ROOT` in a similar fashion to the way that the set of allowable keywords is defined. This would help catch simple typos and any non-approved reasons to use `@enablePreview`. This would also give us a quick and easy way to flag related tests by simply removing the token from the allowable set in TEST.ROOT.
Given there are a large number of tests that currently use `enablePreview`, the tokens in the tag should be optional for now, although eventually they could be mandatory based on the JDK version -- i.e. tests in older versions of the test suite would be allowed to not have any tokens, but tests in newer versions of the test suite would be required to use them.