[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakarta.ee-spec] [Ballot] - Denoting which implementation was used to ratify a specification
|
> On Mar 22, 2021, at 11:00 AM, Paul Buck <paul.buck@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> 2. Provide a link to the Compatibility Certification Requests used for the Ballot at the bottom of the page (https://deploy-preview-337--jakartaee-specifications.netlify.app/specifications/jsonp/2.0/)
Option 2 would be my preference based on the presentation. Options 1 and especially option 3 elevate the status of one implementation over others. Our status quo in the industry is already that one implementation is heavily favored over others. We don't need to codify that at the working group level.
Option 2 has it so that the details about the implementations used in vote (ratification) are in the Release Review section with all other details about the vote/ratification. This has the advantage of being a bit more flexible in form and style. When we fix the rules so that multiple compatible implementations can be used, we'd be well positioned to detail our rational as to why this combination results in a completely passing TCK.
This will likely hit is immediately in Jakarta EE 9.1 where GlassFish 6 is our planned implementation to prove the TCK can be passed on Java 8 and a more recent version of GlassFish will prove the TCK can be passed on Java 11. Having this in the Release Review section allows us to document that and evolve the format of that over time.
We'd also advise that the Release Review section not be considered for marketing purposes. Specifically the versions mentioned should never be updated because they are critical details as in the above case where two different versions of the same implementation are needed. This scenario of vendors dropping support for optional features in their future versions should be expected and ok. Dropping support for older JVM versions and dropping support for legacy features is something all compatible implementations should have the freedom to do. Therefore, the versions under Release Review section should be frozen so we know exactly what release was used and can therefore determine what features were supported at the time.
The list under Compatible Implementations, however, can be freely updated by the vendor to their latest greatest version without consequence.
-David
