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
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec__;!!ACWV5N9M2RV99hQ!dnY_NfEDt6cEJMT0wxcHVd-eTD52inS2PxLAdkEJ1gloc334sJr9-2bstJ2QI_0$