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.