Re: [jakarta.ee-spec.committee] Maintenance Reviews

[Ivar Grimstad <ivar.grimstad@xxxxxxxxx>]

On Fri, Dec 14, 2018 at 5:34 AM Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> wrote:

According to the JCP (2.11.6), in the context of a Maintenance Review:

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"). 

I will add this to the agenda for our next meeting.

I think an example of "implementation-specific enhancements" in the JCP could be to enhance the performance of the e.g. sort() method on e.g. the ArrayList class without changing the behaviour in any way other than that it is faster.

 

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.

+1

 

And, perhaps, formalize that the output of a Service Release is also a Specification Version.

Sounds reasonable

 

What am I missing?

Thanks,

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