Jakarta EE Spec Committee - May 31st, 2023
Attendees (present in bold):
Kenji Kazumura - Fujitsu
Emily Jiang - IBM - Tom Watson
Ed Bratt - Oracle - Dmitry Kornilov
Andrew Pielage - Payara - Petr Aubrecht
David Blevins - Tomitribe - Jean-Louis Monteiro, Cesar Hernandez
Ivar Grimstad - PMC Representative
Marcelo Ancelmo - Participant Member - Abraham Marin-Perez
Werner Keil - Committer Member
Scott Stark - Red Hat - Scott Marlow Enterprise Member
Zhai Luchao - Shandong Cvicse Middleware Co. - Enterprise Member
Guests - Jakarta EE 11 co-release coordinators: Ed Burns, Arjan Tijms
Eclipse Foundation: Tanja Obradovic, Paul Buck (chair)
Past business / action items:
Agenda:
Ongoing tracking spreadsheet of specifications progressing through the JESP version lifecycle
Ongoing work on and resolve Specification Committee’s process enhancements items including those identified in the Jakarta EE 10 retrospective:
See the issues in the board for updates
Emily agree to help progress issues #57 and #59 (also see PR #1679)
05/31 see the issues for Emily’s updates
Issue created by Scott Stark of what needs to be done, see
https://github.com/jakartaee/specification-committee/issues/73
Proposal - shift this topic to the Platform Project, focus is on automation of testing of compliance with the semantic versioning model to flag problems w/ backward compatibility. There are discussions regarding using the OSGi BND tool and the namespace the tool uses.
Note CDI 4.0 did introduce a backward in-compatible change which was inconsistent with the guidance in the Compatibility Requirements page.
Given that situation, we do need to:
Clarify the Jakarta EE semantic versioning model and then
Or we can start with a discussion regarding should Jakarta EE allow backward compatibility changes? Yes
Homework - carefully review the Compatibility Requirements page
Adopt a tool to detect any backward compatibility problems to assure consistency w/ the agreed to semantic versioning model
04/05 A copy of the Backwards Compatibility page was made in a google doc where suggested edits were made and discussed on the call. Further refinements can be made in the document and reviewed in the Committee call on 04/19.
04/19 Continue review and refine the proposed updates to the Backward Compatibility page in the google doc
Discussion was had based on the comments from Scott Stark in the google doc regarding not starting w/ the Backward Compatibility page and evolving that doc, rather start with how semantic version applies
Key question is are we going to allow incompatible changes? If yes, then semantic versioning is an option
In Jakarta EE 10 a number of specs including CDI behavior change made backward incompatible changes
Should Jakarta EE adopt a hybrid versioning model? Not a pure implementation of Semantic Versioning.
Idea: Apply semantic versioning to the component specifications, they are then responsible for how backward compatibility is retained?
Consider adopting a model similar to Java SE?
Straw poll - anyone object to backwards incompatible changes being permitted?
05/03 Call for volunteers to draft our policy for managing backward incompatible changes.
Further discussions were had on how best to manage incompatible changes,
Andrew Pielage (Payara) volunteered to create a draft policy for the committee to review and progress the draft.
See 05/15 email message sent to the Spec Committee mailing list, Subject: Backward Compatibility
05/17 Review the draft, discuss and revise the draft policy.
The draft was presented by Andrew and discussed by the committee on the call. The committee was requested to make comments and suggested edits in the document.
As an interim measure, Ivar will append to issue #863 general guidance that
and that more details of the process to manage such changes will be provided at a later date.
05/31 Continue to review the draft, discuss and revise the draft policy. See document for updates and comments.