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.
