|Re: [jakarta.ee-spec] [External] : TCK release process requirements (continuation from `Process for TCK service releases...`)|
If there are no assertion changes (i.e. the tests don't change)
then re-release can probably be avoided. These updates can use the
micro-version ID bumps.
RESTFul Web Services will need to verify itself with a compatible
implementation that passes both the newly refactored TCK and a TCK
that comes from the Platform TCK project. Personally, I would like
to see both Jersey and GlassFish (with the new RESTful Web
Services implementation) both passing these TCKs prior to the 3.1
ballot. My hope is RESTFul web services project, or through an
arrangement between it and the Platform TCK project, will run
these TCKs against GlassFish (or, if another CI is willing to
provide this service, great) and Jersey periodically -- and
hopefully before either of the TCK releases is updated -- even if
just a micro update. So -- if we find a change breaks the
previously compatible implementation, we can investigate and
correct if necessary.
If the Platform specification (or any other spec that hasn't finished) imposes new or changed requirements (adds or changes an assertion) on RESTFul Web Services, after 3.1 is released -- that forces a new release.
Is this helpful?
 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  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 . 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  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 , 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  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  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.
_______________________________________________ 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$
Back to the top