| [jakarta.ee-spec.committee] Review for approval: Jakarta EE Specification Committee Meeting Minutes - April 19th, 2023 |
The minutes for the April 19th Specification Committee call are below and are also available here. Please review and be ready for approval during our call on May 3rd.
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 (not available)
Zhai Luchao - Shandong Cvicse Middleware Co. - Enterprise Member
Eclipse Foundation: Tanja Obradovic, Wayne Beaton, Paul Buck (chair)
Past business / action items:
Approval is requested for the minutes from the April 5th, 2023 meeting as drafted - Approved.
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
Follow-up on two topics from previous meetings:
Optional features approved resolution: "An individual specification can have optional features, however when a component specification is included in the Platform and Web Profile, and Core Profile an optional feature must be explicitly declared as required, otherwise it is not required. This requirement is noted in the Platform specification.”
Action: Create the issues of what needs to be done including a draft of the Jakarta EE semantic versioning model [Scott Stark]
https://www.eclipse.org/lists/jakarta.ee-spec/msg02845.html
Discussion continues on the mailing list, input to be considered prior to inclusion in the EE 11 Platform spec.
https://www.eclipse.org/lists/jakarta.ee-spec/msg02853.html
“Platform specifications don’t define optional features. An individual specification can have optional features, however when a component specification is included in the Platform and Web Profile, and Core Profile, an included optional feature must be explicitly declared as required, otherwise it is ignored. This requirement is noted in the Platform specification.”
General agreement that the above text is acceptable to the specification committee.
Discussion:
Regarding whether guidance should be provided to component specifications that optional features are discouraged?
Should guidance also be provided to component specification TCK’s need to be configurable to not require the tests for optional features - likely not needed as a TCK challenge could be issued if it was working that way.
Suggestion: Platform project to discuss best practices for component specifications handling optional features
Regarding component specifications:
Note for reference - From August 25th, 2021 - See ballot results for the “RESOLUTION: The Jakarta EE Specification Committee resolves that no new optional features may be added in Jakarta EE 10 and beyond in component, Platform, or Profile specifications.”
This resolution remains in effect and applies adding “new optional features”
Do we want this resolution to stand as written regarding component specifications?
Next steps are with the Platform project to discuss and consider appending the August 25th resolution to the discussion thread.
04/05 - Topic was not discussed by the Platform Project in their most recent call, a reminder will be sent to the chair to include in the next call (04/11?).
04/19 - Proposal: Specification Committee to rescind its 08/25/21 resolution
“RESOLUTION: The Jakarta EE Specification Committee resolves that no new optional features may be added in Jakarta EE 10 and beyond in component, Platform, or Profile specifications.”
and consider it superseded by subsequently approved 02/08/23 resolution above.
“RESOLUTION: Platform and Profile specifications don’t define optional features. An individual specification can have optional features, however when a component specification is included in the Platform and/or Web Profiles, and Core Profile, an included optional feature must be explicitly declared as required, otherwise it is ignored. This requirement is noted in the Platform and Profile specifications.”
Committee’s position the proposal documented above:
No objections were noted regarding the above updates/edits to the 02/08/23 resolution
No objections were noted regarding the 02/08/23 resolution as updated 04/19/23, superseding the 08/25/21 resolution
Formalizing the compatibility requirements for specifications in the JESP and then updating the Compatibility Requirements page of the Jakarta EE Platform project.
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
Update the JESP if needed
Update the Compatibility Requirements page
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?
Consensus: no objections
Next step: Work is required to clarify when and how it is done in managed way
Are there any objections to the current non-voting Specification Committee chair, Paul Buck, continuing to serve for another 12 months?
No objections, the current non-voting chair will serve for another 12 months