Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jakarta.ee-spec] Jakarta EE Spec Committee Approved Meeting Minutes - May 17th, 2023

Jakarta EE Spec Committee - May 17th, 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

 

Eclipse Foundation: Tanja Obradovic, Wayne Beaton, Paul Buck (chair)


Past business / action items:

  • Approval is requested for the minutes from the May 3rd, 2023 meeting as drafted - Approved.


Agenda:

  • Ongoing tracking spreadsheet of specifications progressing through the JESP version lifecycle

    • Getting ready for Jakarta EE 11

  • Ongoing work on and resolve Specification Committee’s process enhancements items including those identified in the Jakarta EE 10 retrospective:

    • Issues with the “enhancement” label are here 

    • Enhancement labeled issues in a project board is here 

See the issues in the board for updates

Emily agree to help progress issues #57 and #59 (also see PR #1679)

05/17 see the issues for Emily’s updates

  • Need to invite Ed Burns (MSFT) & Arjan Tijms (OmniFish) to the Specification Committee calls as EE11 release co-coordinators

    • Paul to take the action invite them both to bi-weekly calls

05/17 The committee chair reached out to both Ed and Arjan for introductions and orientation to the committee’s operating model, no response was received, I will proceed now to invite them to the calls starting on May 31st

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 

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 

  • A feature is marked as deprecated in release N.

  • A feature is then removed in release N+1 (or beyond)

and that more details of the process to manage such changes will be provided at a later date.



Back to the top