Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] Where are we at in regards to Service Releases?
Thanks, Scott.

I found the comment about "no increase in IP scope" for the ops guide.  I'm good with that.  But, you mentioned that you made a comment on each PR.  I can't find anything on the other PR...


---------------------------------------------------
Kevin Sutter
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter

Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)



From:        Scott Stark <sstark@xxxxxxxxxx>
To:        Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date:        02/18/2021 14:14
Subject:        [EXTERNAL] Re: [jakarta.ee-spec.committee] Where are we at in regards to Service Releases?
Sent by:        "jakarta.ee-spec.committee" <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>



Ok, I made a comment on each PR that clarifies the definition enough for me.

On Thu, Feb 18, 2021 at 11:07 AM Kevin Sutter <sutter@xxxxxxxxxx> wrote:
Well, you tell me...  :-)

From PR #1050 (JESP):
  • Service Releases (x.y.z)
    • A Service Release includes only minor changes and/or clarifications over a Major or Minor Release. Specifically, a Service Release must not include any functionality 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 or Release Review is required for a Service Release.

From PR #1047 (Ops Guide)(Note that there would still be a note to the Spec team asking for the review of the PR.  At least one member of the Spec Committee would have to approve the PR and do the actual merging.  We just wouldn't have the formal vote across the whole Committee.)

Creating a Final Service Release Specification # {#creating_a_final_service_release_specification}
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 are permitted in a service release. Although much of the content of the Final Specification still applies, the approval process is simplified for a service release.
  1. The creation and staging of the various artifacts (Specification, API, and/or TCK) are still performed via the initial steps 1 and 2 outlined above.
  2. The creation of Specification PRs in step 5is also required.
  3. The Specification Project team should then send a note to the public Specification Committee mailing listannouncing that the PRs are ready for review.
  4. After the Specification PRs are reviewed and approved by independent specification committee members, the PRs can be merged. The Specification Project team can then release the staged artifacts to Maven Central.


---------------------------------------------------
Kevin Sutter
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail:  sutter@xxxxxxxxxx    Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter

Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)



From:        Scott Stark <sstark@xxxxxxxxxx>
To:        Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date:        02/18/2021 12:54
Subject:        [EXTERNAL] Re: [jakarta.ee-spec.committee] Where are we at in regards to Service Releases?
Sent by:        "jakarta.ee-spec.committee" <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>



As long as we have a clear definition on what a non-functional change is, then this should work.

On Thu, Feb 18, 2021 at 10:49 AM Kevin Sutter <sutter@xxxxxxxxxx> wrote:
Scott,
Thanks!  I agree that the javadoc is an extension of the spec document.  It actually *was* the spec document in most cases in Jakarta EE 8.

When we discussed this on a Spec Committee call, the discussion centered around trusting and assuming the projects will do the right thing and not introduce any functional changes in a service release.  That is, if we have defined what a service release is (with the two proposed PRs), then Spec Projects need to adhere to this requirement of no functional (or behavior) changes in a service release.  And, allow the Spec Projects to deliver service releases on their own schedule and with no formal ballot as long as a major or minor release was performed within the last 12 months.

If it is later determined that a Spec Project violated that requirement, they would immediately be required to go through a full release cycle for a new major or minor release.

And, if it's later determined that Spec Projects in general are violating this requirement, then we'll have to go back to full release reviews with ballots for all major, minor, and service releases.

Would this satisfy your question?

---------------------------------------------------
Kevin Sutter
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail:  sutter@xxxxxxxxxx    Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter

Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)



From:        Scott Stark <sstark@xxxxxxxxxx>
To:        Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date:        02/18/2021 11:55
Subject:        [EXTERNAL] Re: [jakarta.ee-spec.committee] Where are we at in regards to Service Releases?
Sent by:        "jakarta.ee-spec.committee" <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>



So a spec team basically needs sign off from the specification committee on whether a vote can be bypassed. That still is essentially a lazy consensus vote that needs some initiation to involve the specification committee because we don't want to have people outside of the team arguing that spec of api changes were actually made. Several specs do document behavior in javadocs comments and are essentially extensions of the spec document.

On Wed, Feb 17, 2021 at 6:57 AM Kevin Sutter <sutter@xxxxxxxxxx> wrote:
Hi,
I'm confused where we are at in regards to allowing simple Service Releases.  Here are the minutes from when we last discussed this:
We have several Specifications that would like to do a service release (x.y.z) in the very near future.  These are not considered part of Jakarta EE 9.1, but we still need to communicate a process to them.

If I go off of this statement from the minutes:  Is a ballot always required? The Specification Committee acts in its best judgement whether a ballot is needed.
Then, don't we have the liberty to forego a formal ballot for a service release?  And, thus my PRs for updating the JESP and our Operations Guide are valid until we get further clarification defined at the EFSP level?

We are already allowing service releases for the TCK without any fanfare.  We've already done a 9.0.1 and 9.0.2 TCK release.  Can't we do the same thing for the Javadoc updates via the APIs?  As long as we're firm on the requirement of no functional changes (and that's spelled out in the PRs above), then we should be good to go.  Right?

Please comment so that I can provide a better answer to the teams looking to produce service releases.  Thanks!

---------------------------------------------------
Kevin Sutter
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail:  sutter@xxxxxxxxxx    Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter

Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee


_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee


_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee


Back to the top