Jakarta EE Platform Call

Date: 2020-11-10

Present:

• Ivar Grimstad (Eclipse Foundation)
• Kevin Sutter (IBM)
• Tanja Obradović (EF)
• Dmitry Kornilov (Oracle)
• Scott Kurz (IBM)
• Steve Millidge (Payara)
• Kenji Kazumura (Fujitsu)
• Jean-Louis Monteiro (Tomitribe)
• Ed Bratt (Oracle)
• BJ Hargrave (IBM)
• Werner Keil (Individual)
• Ryan Cuprak (Jakarta EE Ambassadors)
• David Blevins (Tomitribe)

Agenda and Minutes

Major vs Point release numbering for Platform

• In the past, Java EE and Jakarta EE only used Major releases (7, 8, 9, 10, …)
• Or, should we allow semantic versioning at the Platform level (9.1, 9.x, …)?
• General consensus on the call was to allow for point releases (semantic versioning)

Timebox the releases or based on feature content?

• Some Specification Projects are already working on updated Specs (major and minor updates) beyond Jakarta EE 9
• Minor versions on a regular cadence was suggested (e.g. 6 months)
• Suggestion to set a goal to release minimum one version each year
• If twice a year, then allow for spring/fall timeframe (to avoid the June/Dec timeframes). Follow Ubuntu’s schedule – April/Oct? March/Sept?

Discussion regarding backwards incompatible changes

• Current Guidelines: https://eclipse-ee4j.github.io/jakartaee-platform/CompatibilityRequirements
• Should we allow breaking changes?
• Deprecate first and remove in next release?
• Give a couple of releases to prepare for incompatible changes?

Jakarta EE 9.1 (recurring agenda item)

• Goal to release early in H1 2021
• If there are other spec ready during the year, another release (minor or major) will be on the table

Jakarta EE NEXT (recurring agenda item)

• NEXT may be major or minor depending on the content

Considerations for major versions

• CN4J Alliance and the impact on Jakarta EE (Jakarta EE, MicroProfile, OSGi, …)
• New specifications
• Major versions of existing specifications