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.