Changes appropriate for a Maintenance Release include bug-fixes, clarifications of the Specification, changes to the implementation of existing APIs, and implementation-specific enhancements. Changes introduced in Maintenance Releases – for example, modifications to existing APIs or the addition of new APIs - must not break binary compatibility as defined by the Java Language Specification.
The document also describes the role of Maintenance Lead and specific details around releases.
Service Releases, as presented in the EFSP, are considered "Bug Fix" releases. The definition of Service Release and Bug-fix are not formalized beyond a simple qualification that Service Releases contain "no significant changes or additions over the base Release". In the absence of any formal definition of what constitutes a significant change or addition, the definition is left to the Project Leadership Chain.
I believe that we can reasonable ask the PMC to assert that the sorts of changes that are acceptable in a JCP Maintenance Release are also acceptable in an EDP/EFSP Service Release (though, I'm not quite sure what is intended by "implementation-specific enhancements").
Regarding approvals, the EFSP has this to say about Service Releases:
Service Releases (bug fixes) for a Specification Version that has engaged in a successful Release Review do not require any further Reviews, but must be approved by a Super-majority vote of the Specification Committee.
How a vote is run, the materials that must be delivered to the Specification Committee in advance of a vote, timing considerations, etc. may be formalized in the implementation of the process.
The one possible oversight that I can see is that the EFSP specifically states that:
With the successful completion of a Release Review, including approval of the Specification Committee by a Super-majority vote, a Specification Version is Ratified and the associated artifacts can be promoted and distributed by the Specification Committee as a Final Specification.
This does not make allowances for Service Releases. I believe that this can be corrected by removing the reference to the Release review and going with something like this:
With the <strike>successful completion of a Release Review, including</strike> approval of the Specification Committee by a Super-majority vote, a Specification Version is Ratified and the associated artifacts can be promoted and distributed by the Specification Committee as a Final Specification.
And, perhaps, formalize that the output of a Service Release is also a Specification Version.
What am I missing?
Thanks,
Wayne
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
