Date: 2023-12-12
Present:
- Jan Westerkamp (iJUG)
- James Perkins (Red Hat)
- Ed Burns (MSFT)
- Brian Stansberry (Red Hat)
- Jared Anderson (IBM)
- Emily Jiang (IBM)
- Nathan Rauh (IBM)
- Thomas Watson (IBM)
- Petr Aubrecht (Payara)
- Ivar Grimstad (Eclipse Foundation)
- Scott Stark (Red Hat)
- John Clingan (Red Hat)
Agenda and Minutes
2024-01-30 deadline for release reviews
- According to the waves, first wave needs to be 100%:
- API done
- TCK done
- Spec document (if applicable) done
- At least one Compatible Implementation done
- Emily
- Observes there is effectively no time between M1 and asking for the release review on 2024-01-30.
- Suggests we give specs the opportunity to give feedback on this aggressive deadline.
- Arjan suggested we reinterpret the 2024-01-30 deadline to mean that the Wave 1 Wave 1 - N specs will be ready at this time.
- Concern about JSON-P.
- The commit graph looks very sparse.
- Many open PRs.
- Needs some dependencies to be updated.
- Ivar and Nathan observed we had granted Concurrency to be as late as 2024-03-29. This lead Ivar to suggest
- Wave 1, 2, 3 and 4 2024-01-30 M2
- Wave 5 2024-02-29 M3
- Wave 6 and 7 2024-03-29 M4
- Wave 8 2024-05-31
- For each of the above bullet points:
- The specs that are declared as final will include their final version
- All other specs must produce another milestone release (or Ed/Arjan will produce it for them, by simply re-releasing the existing thing with a new version for M2, etc.).
Jakarta.enterprise.cdi-el-api.jar in 4.1.0-M1 depends on expression language 5, not 6.0.0-M1
- Do milestones in the same waves next time, so dependencies are properly updated?
- Retrospective comment: we should observe the milestone ordering when performing the milestone release activities. \
Faces proposes changing version for EE 11 from Faces 5.0 to Faces 4.1
- Do we need a new vote for 4.1?
- There isn’t an API for M1 in maven central yet for 4.1
- Ivar shared the plan to bring this up at spec committee 2023-12-13.
- Ask for any objections (hope not).
- Content: remove any breaking changes.
- Plan as same as 5.0 but without the breaking changes.
- Emily: update to 4.1 with a PR to the release plan.
- Jea-105-the-big-table: What to do?
- Consider this big table from the platform spec.
- Based on my understanding of the ruling of the spec committee as described in jea-101 the job to be done in JEA-105 is to
- Remove all rows with OPT.
- Fix the header text so it does not mention any of this REQ, POPT, OPT business.
- Remove the Status column, since everything is required.
- Do I have this right?
- Jea-106-anything-else-to-start-removing?
- jea-249-Figure-1
- “Optional in Jakarta EE N” box. Do we need it?
Schemas
- Players
- Pages 4.0 depends on EL 6 M1
- Tags 3.0 (JSTL) depends on EL 5 M1
- Problem
- We cannot have this mismatch due to OSGi.
- Proposed resolution
- Do a Tags 3.1 which increases the dependency on EL to be 6 M1.
- This requires specification committee action to approve the release, even if the only thing changing is incrementing the EL dependency level.
- Timeframe: target this to Milestone 2.
Are there plans to fix the dependency issues on Jakarta Transactions?
- The current version contains circular dependencies to outdated CDI versions (!)
- Doing a Major Release would fix this.
- Jared observed this is a provided dependency
- <dependency>
<groupId>jakarta.enterprise</groupId>
<artifactId>jakarta.enterprise.cdi-api</artifactId>
<version>3.0.1</version>
<scope>provided</scope>
</dependency>
- Therefore this is a dependency update, and therefore not a reason for a major release version.
- Jan: We need to update to a provided CDI 4.x (with a breaking change to CDI 3.x), a Maven project sees a breaking change in Jakarta Transactions, derived from the CDI dependency.
- There is also a Jakarta EJB compile dependency to Jakarta Transaction that need to be fixed
