David Blevins wrote on 9/5/19 3:45 PM:
We don't have an established protocol for handling updates like
this. I propose the following as a bare minimum:
- JSONB 1.0.1: We get TCK verifications from *both*
GlassFish 5.1 and OpenLiberty in the form of JSONB certification
requests against the new sha256. We then publish immediately.
I published the 1.0.0 TCK moments ago, so I'm happy to do that.
It would be Yasson, not GlassFish, and whatever implementation
OpenLiberty is using. I don't think we need a new certification
request for Yasson since we're not required to upgrade to
the new version of the TCK, but we'll run it anyway to make sure the
TCK is working.
OpenLiberty isn't planning to certify the components until sometime
later, so I don't think we need to hold up the JSONB TCK release
until then.
- CTS 8.0.1: We get TCK verifications from *both*
GlassFish 5.1 and OpenLiberty in the form of Full and Web
Profile certification requests against the new sha256. We hold
the binaries, add this additional TCK link and certification
requests to the Web and Full PRs. We publish all TCKs when the
votes complete.
Yes, we'll publish the 8.0.1 version of the platform and web profile
TCKs after the specs are approved.
Note: I think the spec web pages should always refer to the latest
versions of the TCKs, so when we publish these new versions we'll
update the spec web pages to refer to them instead of the previous
versions. The previous versions are still valid and still
available, so if you're already using them you can continue using
them, but anyone looking at the spec pages to find the TCK should
find the latest version.
|