Re: [jakarta.ee-spec] [External] : Re: Issue for call tomorrow

[David Blevins <dblevins@xxxxxxxxxxxxx>]

I'd be significantly more likely to get on board with this than allowing TCK RCs that are different binaries than the final TCK.  We'd want to have some clear requirements for the source being published and referenced in the CCR -- perhaps a link to a src.zip or a git link that includes the hash.

Though I do wonder if there isn't merit in forcing spec projects to do RCs so compatible implementations are not faced with this problem in the first place?

I also have to ask are we actually comfortable with a scenario were say Jakarta EE X is released, we use our budget to make a big splash and the only platform implementation available is a snapshot?

If not, then we need to be extremely clear on what exactly we will allow and/or how we'll handle that scenario when it is presented.  As well as the requirements for how this snapshot binary is preserved so it isn't accidentally overwritten or lost to the world.  It's difficult to imagine these rules not inadvertently recreating the concept of a release.

These are all things we don't have to think about when the implementation binary is any sort of release (RC, Milestone, Beta, Alpha, Final, anything).  Everything has tradeoffs.


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Jan 25, 2022, at 5:38 PM, Scott Stark <starksm64@xxxxxxxxx> wrote:
> 
> +1
> 
> On Jan 25, 2022 at 5:25:28 PM, Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:
>> One thing I would like to exclude is any requirement that a compatible 
>> implementation, used for release ballot, must be exactly build-able at 
>> any time in the future.
>> 
>> The compatible implementation used for release ballot must be 
>> open-source. We can require that the source be preserved (we kind of 
>> imply that the candidate be "released" in some manner but I don't 
>> believe we are detailed in that requirement and I don't think we need to 
>> be). In my opinion, it should not be an obligation of a prospective 
>> ballot CI to provide, nor support building of that release at any time 
>> in the future. (If a prospective ballot CI wants to offer this -- great 
>> -- it simply is not an obligation.)
>> 
>> One issue that frequently comes up in the product release end-game is 
>> the need to update pom file GAVs from <package>.bxx.yy (bxx or rcx or 
>> whatever) to <package>.yy. Most commonly this is done when all the 
>> various components have finalized their releases and the project team 
>> does a sweep that moves all the prospective-final GAVs to their 
>> final-final GAVs. In our current release methodology, an early ballot CI 
>> may need to wait for quite some time before all the dependencies which 
>> were used to build and validate /that/ implementation become final in 
>> themselves.
>> 
>> If we require source preservation or tagging or whatever -- I would 
>> propose "for reference only" be the totality of what is required. Pom 
>> file changes (like I've described above) should not invalidate the 
>> prospective CI. Nor, would I say that inclusion of components that are, 
>> themselves still evolving, be disallowed.
>> 
>> The CI must pass the TCK. The TCK includes tests and instructions. The 
>> Specification Team and the CI implementer assert that all the tests 
>> cover what they should cover (behavior and signatures). That's all there is.
>> 
>> Even if we wind up not agreeing to this point, we should clarify this 
>> (whatever the prospective CI requirements are) so it's clear to our 
>> community.
>> 
>> -- Ed
>> 
>> On 1/25/2022 12:56 PM, David Blevins wrote:
>>> Agree.  If the signature tests pass, all is fine and the vendor is allowed to use their own API jars.  In some cases those API jars are implementations: Faces, Activation, Mail, etc.  There are other situations like JACC where the API jar can't really be considered an implementation, but there is definitely significant code there.
>>> 
>>> We'd likely want to document those requirements in the JESP as the EFSP is what currently holds the open source requirement.
>>> 
>>> We may need to add some clarification on the API jars produced by specification projects as people are increasingly referring to them as "the official" jars, implying 1) all other jars are not official or lesser and 2) they must be used by the compatible implementation used for ratification.  Neither is the case.  We need some explicit text that says we have no concept of "the official" jars and any jars that pass the TCK and signature tests are equivalent.
>>> 
>>> For Jakarta EE 8 our compatible implementation was a pre-Eclipse version of GlassFish that did not ship the jars produced by the Specification Projects.  We did do some work to ensure the Specification Project-produced jars could pass a TCK run.  If we have thoughts that this should or does not need to happen again if a compatible implementation does not use the Specification Project-produced jars, we should write that down too.
>>> 
>>> 
>> _______________________________________________
>> jakarta.ee-spec mailing list
>> jakarta.ee-spec@xxxxxxxxxxx
>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
> _______________________________________________
> jakarta.ee-spec mailing list
> jakarta.ee-spec@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec