| Re: [jakarta.ee-spec.committee] Release or Service Release for Specification Projects |
Well, that's up to what the PMC defines as a service release, right?
A Specification Team may consult with their PMC and Specification Committee to determine precisely what constitutes a minor change and/or clarification.
Please review and correct my update to the How to page.
Wayne Beaton wrote on 7/25/19 11:58 AM:
So as long as there's at least one release on the project's release page, and clicking through to that release shows that it was successful, they can do a service release, right?
At the risk of being overly pedantic...
No. A project can do a service release so long as the project's release page shows a successful release review for the major or minor release that the service release is based on.
The number of releases ("at least one") is irrelevant.
For example, Jakarta Servlet can do a 4.0.3 service release based on the successful 4.0.2 release. Jakarta Servlet could not do a 4.1 release as a service release.
Wayne
On Thu, Jul 25, 2019 at 2:28 PM Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
So as long as there's at least one release on the project's release page, and clicking through to that release shows that it was successful, they can do a service release, right? I guess we need to update the How to page with that additional detail. I can do that...
(It might be nice if the type and status were included on the summary page.)
Wayne Beaton wrote on 7/25/19 10:51 AM:
The presence of a prior release review record (in the "successful" state) is sufficient.
The requirement is that a service release must be based on a previous major or minor release. As the first release from the Eclipse project, for example, Jakarta Servlet 4.0.2 was a major release (in the sense defined by the EDP), so it could follow up with a service release (e.g., 4.0.3).
There's no time restriction for service releases.
Wayne
On Wed, Jul 24, 2019 at 9:43 PM Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
Thanks, Wayne.
Is there an unambiguous approach for determining that a project is eligible for the "service release" approach? For example, is the presence of a release record from a release review dated within a year sufficient? We need to know what to tell each project that lets them figure out whether they need to do a release review.
Wayne Beaton wrote on 7/24/19 6:30 PM:
To engage in a release review, each specification project team must:
- Create a Release record in the PMI (the Release record should include the release name, date, and a sentence that describes the intention behind the release);
- Submit their IP Log for review;
- Request PMC approval of the Release and corresponding release documentation (PMC approval request is an email to the PMC mailing list, a single +1 from any member of the PMC indicates approval); and
- Create a PR against the "specifications" repository that completely describes the contents of the Specification Version that they're releasing.
According the process, the project team must also notify the EMO. In practice the EMO monitors the IP Log submission and the PMC approval request and initiates the review process based on that.
The Specification Committee Chair (or their designate) will initiate the ballot (I am currently the designate for the interim Chair). The timing and actual trigger of the start of the ballot was a topic of discussion today's call.
All of the above definitely applies to Specification Projects that have not already engaged in a release review. This includes Jakarta EE Platform, Jakarta CDI, Jakarta Bean Validation, Jakarta Batch, and Jakarta Server Faces.
While not a specification project, the Eclipse Jakarta EE TCK will have to engage in a Release Review (since it's not a Specification Project, no Specification Committee ballot is required, so skip step 4).
Since most of our Specification Projects have already successfully engaged in a Release Review, the Specification Committee may choose to designate the Jakarta EE 8 follow up as a Service Release. Per the EFSP, a "Specification Team may consult with their PMC and Specification Committee to determine precisely what constitutes a minor change and/or clarification."
Something that I hadn't thought of on the call is whether or not the addition of a Specification Document may be considered as minor and/or a clarification.
For example, the Jakarta Servlet project engaged in a release last year (it had a different name, but it was the same project). The Jakarta EE 8 release will contain no new functionality over and above what was included in that release, but will include a Specification Document that it did not previously have. I have some thoughts about how we can argue that the addition of a Specification Document that is based on Javadoc that was included in the previous release can be reasonably thought to be a clarification.
If the Specification Committee determines that the upcoming release is a Service Release, we can skip steps 2 and 3.
In practical terms, submitting an IP Log and requesting PMC approval should take about two minutes for a committer. Processing the IP Logs requires a pretty significant investment from me, and all of those requests for PMC approval will require that the PMC respond to them all (so it's far more work for me and the PMC than it is for the project team).
I'm a big fan of not processing 30+ IP Logs.
HTH,
Wayne--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
_______________________________________________ jakarta.ee-spec.committee mailing list jakarta.ee-spec.committee@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.