[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakarta.ee-spec] [External] : Re: Issue for call tomorrow
|
Regardless what we decide, we should be clear that implementations are
not treated exactly the same as Specifications -- By specification I
mean all of it (the spec. docs., the Spec. Java Doc, the TCK and all of
it's accompanying documentation). I am on board that API binaries do not
need to be a strictly "controlled."
On 1/25/2022 6:00 PM, David Blevins wrote:
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.
