forked from jakartaee/platform
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge remote-tracking branch 'upstream/gh-pages' into gh-pages
- Loading branch information
Showing
2 changed files
with
88 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,87 @@ | ||
| # Jakarta EE Platform Call | ||
|
|
||
| Date: 2024-01-09 | ||
|
|
||
| Present: | ||
|
|
||
| * James Perkins (Red Hat) | ||
| * Jared Anderson (IBM) | ||
| * Emily Jiang (IBM) | ||
| * Jim Krueger (IBM) | ||
| * Nathan Rauh (IBM) | ||
| * Tom Watson (IBM) | ||
| * Ivar Grimstad (Eclipse Foundation) | ||
| * Arjan Tijms (OmniFish) | ||
| * David Matejcek (OmniFish) | ||
| * Ed Burns (MSFT) | ||
| * Lukas Jungmann (Oracle) | ||
| * Tanja Obradovic (Eclipse Foundation) | ||
| * Scott Marlow (Red Hat) | ||
| * Petr Aubrecht (Payara) | ||
| * Nathan Erwin (Individual) | ||
| * Scott Stark (Red Hat) | ||
| * Cesar Hernández (Tomitribe) | ||
|
|
||
| ## Agenda and Minutes | ||
|
|
||
| ### Big ticket item for this sprint: EE 11 M02 | ||
| * [JEA-243](https://dev.azure.com/jakarta-ee-azdo/jakarta-ee-azdo/_workitems/edit/243) Release review for all Wave 1, 2, 3, 4 specs: due 2024-01-24. | ||
| * [Ed’s 2023-12-13 email to spec-project-leads](https://www.eclipse.org/lists/jakartaee-spec-project-leads/msg00851.html) | ||
| * I realize this is overshadowed by JEA-83. See below. | ||
|
|
||
| ### [JEA-83](https://dev.azure.com/jakarta-ee-azdo/jakarta-ee-azdo/_workitems/edit/83) Baseline Java SE level for EE 11 | ||
| * Release co-coordinator thoughts | ||
| * We understand these kinds of things unavoidably surface when you try to crank out releases. | ||
| * Even so, this strikes us as an unfortunate wrinkle. | ||
| * We thought the decision to require SE 21 was one of the most important features of EE 11. This was our understanding before agreeing to take the role of release co-coordinator. | ||
| * Multiple parties confirmed this understanding. | ||
| * Emily also observed few specs are using new 21 features. | ||
| * Going back on this seems like a big deal. We do not take it lightly. | ||
| * Note: GlassFish 8 at least will require SE 21+ | ||
| * We observe there seems to be a historical precedent of fear for whenever a new “big” or LTS release comes out. EE7, EE8, had this. | ||
| * Context review | ||
| * Historical issue [gh-platform-553](https://github.com/jakartaee/jakartaee-platform/issues/553) | ||
| * Scott characterized this issue as demonstrating that it takes two years for an LTS to be adopted. | ||
| * Can we close this issue and point to 820? | ||
| * Recently opened issue [gh-platform-820](https://github.com/jakartaee/platform/issues/820) | ||
| * Red Hat is stating that they are not able to have SE 21 as a baseline for any products at this time. | ||
| * Questions to requestor and responses | ||
| * Have you considered alternatives? | ||
| * Why have other implementers not raised this issue? | ||
| * The new wrinkle | ||
| * Because every component spec has its own implementation, and Red Hat **is** the implementation of CDI and Validation, and other downstream implementations need that. | ||
| * Red Hat is seeking clarity: are they allowed to deliver their implementations so that they run on 21 but are compiled on 17? | ||
| * Eclipse process expert perspective | ||
| * | ||
| * Other thoughts | ||
| * Rest spec has thoughts on this. | ||
| * Thomas Watson asserted | ||
| * We are conflating issues. | ||
| * Emily asserts the steering committee has mandated EE 11 specs compile against 21. | ||
| * Thomas observed to implement this mandate, there must be some spec text that binds implementations to this mandate. | ||
| * What options can we see right now? | ||
| * It seems we must resolve this issue right away. It blocks EE 11M02. | ||
| * Ivar recommends we should define what we want | ||
| * Then go to the spec committee and say this is what we want. | ||
| * Then go to the steering committee and say we heard what you recommended, but this is what we’re doing. | ||
| * Ed tried to identify the key sub-stakeholders on this | ||
| * Red Hat: Scott | ||
| * IBM | ||
| * Thomas | ||
| * Nathan | ||
| * Emily | ||
| * OmniFish: Arjan | ||
| * Note: | ||
| * REST has an opinion on this. | ||
| * Emily observed the REST project, and its veto policy, makes this problematic. | ||
| * MicroProfile has an opinion on this: compile low, support high. | ||
| * Get the plan of record of the spec committee on the minimum SE requirement for EE 11. | ||
| * According to Eclipse practice the Steering Committee can only recommend on the matter of the minimum SE requirement for EE 11. | ||
| * What does the spec committee have power to do on this point? | ||
| * They can fail reviews if they don’t agree with what is done. | ||
| * Practically speaking this functions as a mandate. | ||
|
|
||
| ### Ratifying Compatible Implementation for EE 11 | ||
| * Our release plan has | ||
| * all the component specs completing release review in Q1CY24. | ||
| * The Ratifying Compatible Implementation is not due to be delivered until June/July 2024. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -8,6 +8,7 @@ | |
| * [2019](#2019) | ||
|
|
||
| ## [2024](#2024) | ||
| * [2024-01-09](2024/2024-01-09.md) | ||
|
|
||
|
|
||
| ## [2023](#2023) | ||
|
|
||