A Service Release includes only minor changes and/or clarifications over a Major or Minor Release. Specifically, a Service Release must not include any significant new features and/or breaking changes. A Specification Team
may consult with their PMC and Specification Committee to determine precisely what constitutes a minor change and/or clarification.
A Specification Team must have engaged in a successful Release Review for a Major or Minor Release prior to engaging in a Service Release. No Progress Review is required for a Service Release; the Specification Team must,
however, engage in a successful Release Review.
In the nature of Concurrency release, it contains minor changes - not significant new features nor breaking changes.
>From the above statement, a service release of Concurrency tck is needed not a minor release.
However, Jakarta TCK Process demands for a minor release if any test updates are introduced. Why not just voting on the proposal Paul proposed, which sounds more logical?
I also suggest we revisit the TCK process after EE 10 and consider reworking the sentence to make it more flexible.
How Tests May be Added to a TCK
The only time tests may be added to a TCK are in a major or minor release. A service release which updates the exclude list MUST not have test additions or updates (see exception below for addressing newer Java SE versions).
If we do a full-fledged minor release, I understand some companies don't want to cut the voting period short. It will easily take 4 weeks.
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
From: jakarta.ee-spec.committee <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> on behalf of Paul Buck <paul.buck@xxxxxxxxxxxxxxxxxxxxxx> Sent: 22 July 2022 18:48 To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx> Subject: Re: [jakarta.ee-spec.committee] [External] : Re: Concurrency team is looking for guidance on release of fix that unblocks the EE 10 release
I am going to initiate the ballot, as needed we can get into this one in our next meeting (27th). Thanks ... Paul On Fri, Jul 22, 2022 at 1:26 PM Ed Bratt <ed.bratt@xxxxxxxxxx> wrote: So, it's not just a shuffle of tests then.
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
I am going to initiate the ballot, as needed we can get into this one in our next meeting (27th).
I guess the alternate approach is propose a new minor release but I guess that would take a plan ballot followed by a release ballot. That would take, minimum 4 weeks (two weeks for each ballot). If we could do these together, maybe we could get this done
in two weeks.
Other than a resolution granting an exception, has any other solution been proposed, maybe in the committer team discussions?
It seems, at this point, we might also consider taking up this exception by in-person vote at the next committee meeting. Or, is e-mail approval the only way for things like this?
-- Ed
On 7/21/2022 7:27 PM, Scott Stark wrote:
There are new tags for exclusions, and there are changes to tests and rearrangement of tests. It is really the 'changes to tests' that has been questioned as being against the TCK process and in need of approval.
Is there disagreement regarding the statement that there are no new tests, this only re-arranges existing tests? If not, I wonder if a resolution granting an exception is even necessary. We did release a bug-fix patch for Authorization that moved the source
location of Authorization TCK tests from the Jakarta EE Platform TCK into the Jakarta Authorization TCK. In some ways, that is a similar type event (tests in one place were moved to another place but there wasn't a minor release update).
So, if there isn't disagreement that this is just shuffling of the tests, I'd be tempted to suggest we just recommend the Concurrecy project just proceed with production of a patch release. Skip the resolution.
-- Ed
On 7/21/2022 4:35 PM, Paul Buck wrote:
Hi Kenji,
Thanks for catching the typo.
The Jakarta EE TCK Process is authored by and owned by the Specification Committee, we can therefore authorize an exception by way of a ballot. In the future,
we could consider a revision to the TCK Process if we thought it was warranted based on other projects asking for the same exception.
but I wonder if the specification committee has a power to grant the exception against TCK Process.
Or do we need to change TCK Process itself ?
-Kenji Kazumura
From: jakarta.ee-spec.committee <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
On Behalf Of Paul Buck Sent: Thursday, July 21, 2022 11:45 PM To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx> Subject: Re: [jakarta.ee-spec.committee] Concurrency team is looking for guidance on release of fix that unblocks the EE 10 release
I have drafted a backgrounder statement and a resolution, if there are no objections, I will get the ballot underway on our public mailing list on Friday (22nd).
Background: Concurrency was added to the Web Profile for Jakarta EE 10, therefore existing
Concurrency tests needed to be added to the Web Profile TCK. The existing Concurrency tests were deployed in EAR files and used remote EJB, neither of which are supported in the Web Profile. The tests in scope here are not new tests, they are existing tests
that have been updated to no longer depend on EAR or remote EJB, there is no change to either the functionality or API testing. TheJakarta EE Test Process states that a "... service release which updates the exclude list MUST not have test additions or
updates". Given there are no additions, and the updates have no effect on functionality or API testing, granting the Concurrency project an exception to update their TCK is service release is reasonable.
Resolution: It is resolved that the Jakarta EE Specification Committee grants a Jakarta EE TCK Process
exception to the Jakarta Concurrency project to update the tests in their Jakarta Concurrency 3.0 TCK to no longer depend on EAR or remote EJB when executed in environments that does not support these technologies, and deliver these changes as a service release.
Right then, is there a spec committee representative that is able and willing to draft a suitable resolution with supporting preamble/rationale for this exception that the spec committee can consider, discuss and then
ballot on?
On Tue, Jul 19, 2022 at 5:51 PM Scott Stark <sstark@xxxxxxxxxx> wrote:
The changes would be more associated with the TCK process since the concurrency TCK is what is being updated. There are no changes to the specification or APIs.
There it says a "... service release which updates the exclude list MUST not have test additions or updates".
The current proposal would violate that. The concurrency team is seeking an exception to this since the concurrency TCK was not validated against any Web Profile release as part of the concurrency component specification and now standalone TCK.
I draw your attention to the Jakarta EE Specification Committee Operation document section section on
Creating a Final Service Release Specification wherein it documents: "There is no formal release review required for a Specification service release (x.y.z) as long as the JESP definition of a “service release” is adhered to. That is, no functionality changes
or increase in IP scope are permitted in a service release."
So the question here I think is does "...fixing the current Web Profile set of TCK tests in a 3.0.x release so as not to lose coverage and unblock the platform release." adhere to the
JESP definition of a "service release"?
... Paul
On Tue, Jul 19, 2022 at 12:10 PM Scott Stark <sstark@xxxxxxxxxx> wrote:
To follow up on this after the platform call today, what the Concurrency team is asking for is no opposition to fixing the current Web Profile set of TCK tests in a 3.0.x release so as not to lose coverage and unblock
the platform release. Barring any opposition to the approach in the next couple of day they will assume this approach will not be challenged.
If there is opposition, the mechanism for creating a minor release of a TCK needs to be clarified at the next specification committee meeting. As I understand the current process, it would require a new minor project
release which would entail a project plan, voting, etc.
As per https://www.eclipse.org/lists/cu-dev/msg00389.html,
Concurrency team would like to know if they can release a service release of the TCK with the change that fixes Web Profile support. I think that this blocks EE 10 from going final.
Do they need to start a new ballot or a service release?
