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

[David Blevins <dblevins@xxxxxxxxxxxxx>]

> On Jan 25, 2022, at 2:54 PM, Emily Jiang via jakarta.ee-spec <jakarta.ee-spec@xxxxxxxxxxx> wrote:
> 
> +1 on clarifying this.
> For rectifying a spec, the viable solution is to use release candidates for both APIs and TCKs to avoid chicken egg situations.
> 
> It has been a requirement that the TCK used for certification was the proposed final TCK, but not the APIs.
> Based on what I said above, TCKs used for ratifying a spec can be a RC as well. This will certainly help with the specs that contain both APIs and TCKs.

We have some flexibility baked in as our rules as they exist now don't care about anything but the SHA256 hash.  The rule is the hash in the CCR and the hash of the proposed final TCK must match. That provides some flexibility (binaries can be renamed from RC to Final), but also some clear restrictions (we can't use separate builds that).  

The usable options with the rules as they are now:

# Republish the RC binary as final

It would be possible for someone to promote a TCK labeled RC to Maven Central, allow people to use that to create CCRs, then come release time upload that exact same TCK binary again as final and use it for the vote with no need for anyone to rerun the tests.  The hashes of both the RC and final will be the same, so all is good.

Maven does have commands both download and upload binaries, so it could easily be scripted in a Jenkins job maintained by the spec project.  It would download the RC and republish it with a final version number, make final git tag by copying the RC tag.  Done.

# Rerun the tests one last time

It would not be possible for the TCK to be rebuilt from source after the RC and call that close enough.  The compatible implementation would need to run the final TCK one last time against the new final TCK binary/hash and update the hash in the CCR.

We have a 60-day retention in jakarta.oss.sonatype.org so things like that can happen without risk of losing the binaries.  A simple Jenkins job maintained by the CI to rerun tests is a small investment considering the role the TCK plays.

# Explicit Non-existant scenarios

There explicitly aren't any scenarios where CCRs use one binary/hash, the final TCK is a different binary/hash and we call that close enough.

# Votes won't always pass on the first try

One thing to keep in mind is we need to design for failure.  We need to plan for what we'll do if a vote doesn't pass and we might potentially have two sets of final-looking binaries floating around causing potential confusion/mistakes.

The hashes give us 100% confidence we are promoting what we intend to promote regardless of how many nightly builds, RCs and proposed final TCKs are floating around.  They also give us 100% confidence that someone filing a CRR has also not been confused by these same nightly builds, RCs and proposed final TCKs are floating around.  There's no way to allow separate binaries to be used without losing all that confidence in both our spec promotion and CCR approvals.



-David