Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Release plan revisions to mitigate impact of gh-platform-820 and preserve June/July delivery of EE 11

Why are we requiring compatibile implementations to certify under multiple Java SE versions? This was not the case with earlier Jakarta EE versions.

Alasdair

On Jan 15, 2024, at 2:18 PM, Ed Burns via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

Executive Summary
  • Platform project keeps the June/July 2024 target for having an EE 11 Ratifying Compatible Implementation.
  • Platform project adjusts JDK compilation requirements:
    • Component spec TCKs and platform TCK must compile under 17.
    • A compatible component impl must pass their component TCK when run under 17 and also 21.
    • A compatible platform impl must pass the platform TCK when run under 17 and also 21.
  • Platform project adjusts "release review" targets for component specs: move "release review" targets all out by one month relative to the schedule sent to Spec Project Leads on 2023-12-13.
    • Wave 1, 2, 3, 4 specs release review by 2024-02-29
    • M2 release
    • Wave 5 specs release review by 2024-03-29
    • M3 release
    • Wave 6, 7 specs release review by 2024-04-27
    • M4 release

  • The key condition to make this plan possible: the GlassFish community is willing and able to deliver an implementation of EE 11 compiled under 17, but passing the platform TCK under 17 and also 21. The release coordinators expect more community involvement on the Jakarta Data implementation for GlassFish, especially from Red Hat, to achieve this goal.
Details
 
On 2023-12-20, Red Hat opened gh-platform-820. This issue requests, "there still must be support for Java SE 17 as a valid runtime for certification." We spent the 2024-01-09 platform project call discussing this issue. Since then, the release coordinators have been working to revise the release plan to accommodate this request, while preserving the delivery schedule and maintaining buy-in from implementation vendors.
 
We believe the revised plan achieves this objective. We ask you to read it and understand it carefully. If you think it's unachievable, now is the best time to say it.
 
We will discuss this tomorrow. We aim to modify the Jakarta EE 11 Release Plan right after the meeting and convey the changes to the spec and steering committees.
 
Thanks,
 
Ed and Arjan
 
P.S. The long-standing policy of considering specification binaries, in maven central or anywhere else, as a non-normative convenience remains unchanged. The platform project is silent on this matter. But because the platform project does mandate a specific JDK requirement for compatible implementations passing the component or platform TCK, specification binaries are practically constrained to follow that mandate.  
 
 
| edburns@xxxxxxxxxxxxx | office: +1 954 727 1095
| Calendar Booking: https://aka.ms/meetedburns
| 
| Please don't feel obliged to read or reply to this e-mail outside
| of your normal working hours.
|
| Reply anonymously to this email: https://purl.oclc.org/NET/edburns/contact
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev


Back to the top