| [jakarta.ee-spec] TCK release process requirements (continuation from `Process for TCK service releases...`) |
Hi,
[1][2][3][4][5][6][7] are from the "Process for TCK service
releases that include TCK updates for running signature tests on
newer JDK versions..." discussion thread. I am starting a new
thread with the subject that Ed Bratt suggested as I agree that we
need a new thread for this sub-discussion.
I am responding here to the last message from Ed [7] for which I will paste his message. I hope this is clear:
> I would have expected, when we hold a ballot, for any Spec.,
those components are expected to be ready for all required
compatibility configurations -- both with a stand-alone compatible
implementation and with a Platform implementation. If no suitable
platform is
> available at the time the component is finished it is
plausible that the platform will simply have to conform to the
component TCK. If a Platform implementation is required and none
is available, that component won't be ready for ballot. In a case
where the Platform is,
> for some reason or other, going to imply changes on the
component -- that seems like new requirements and a new release to
me.
The concrete situation is for how we will deal with the EE 10 Platform TCK tests that *could* get added on top of the jaxrs-api/pull/1002 [8]. IMO, in order to release EE 10 in the first quarter of 2022, we need the overall development process to be as streamlined as possible for this brand new situation where we are adding new features to many EE specifications and also starting the TCK refactoring to improve how easy it is to add new TCK tests (as well as maintain the TCK tests for the future).
I assert that the RESTFul Web Services (3.1) Spec API ballot
should only be run once for the EE 10 release and the same for all
other Specs as that is what is required and that can include the
Java SE TCK tests. But what are the options for releasing [8]
Platform level tests that do not require any Spec Ballot to be
repeated?
> OR put another way: if the tests can't be frozen, then the Spec. won't be ready for a ballot.
So the Platform level tests cannot be frozen until the Platform
spec is frozen but if some (new for EE 10) Platform level tests
will be in the jaxrs-api repository [9], those platform level
tests shouldn't be validated until after all of the Spec Ballots
have completed. IMO, the team maintaining the Platform level
tests in the jaxrs-api repository [9] will need a way to fix any
test defects identified prior to the Platform spec being
released. Also IMO, the Platform TCK tests in the jaxrs-api
repository [9] need a way to be released along with any TCKs
produced by the Platform TCK.
> We should always operate on the principle -- the Spec
encompasses all of the Spec. text, the Spec. binary artifacts, and
the TCK. If any of these change -- we are effectively changing the
Spec. (I need to keep reminding myself, Compatibility tests are
not the same as
> product tests.) Under this principle, the tests are not
subject to change after the release ballot is started. We did a
bit of a sleight of hand to allow for adding additional JDK
support between 9 and 9.1 but that was expressly not supposed to
cause any test changes. There
> might have been other TCK test changes, but those all should
have been due to challenges or other errata type fixes.
The change now is that we need coordination of releasing Platform
TCK tests that are maintained by the Standalone SPEC API teams.
IMO, we should identify at ballot time if any Platform level tests
are maintained by the relevant Spec so we can coordinate linking
that Spec API with the Platform Spec final release process.
Scott
[1] https://www.eclipse.org/lists/jakarta.ee-spec/msg01950.html
[2] https://www.eclipse.org/lists/jakarta.ee-spec/msg01951.html
[3] https://www.eclipse.org/lists/jakarta.ee-spec/msg01952.html
[4] https://www.eclipse.org/lists/jakarta.ee-spec/msg01953.html
[5] https://www.eclipse.org/lists/jakarta.ee-spec/msg01954.html
[6] https://www.eclipse.org/lists/jakarta.ee-spec/msg01955.html
[7] https://www.eclipse.org/lists/jakarta.ee-spec/msg01960.html
[8] https://github.com/eclipse-ee4j/jaxrs-api/pull/1002
[9] https://github.com/eclipse-ee4j/jaxrs-api