[jakarta.ee-spec.committee] Compromise for approval of Jakarta EE 8 spec

[Bill Shannon <bill.shannon@xxxxxxxxxx>]

In order to complete Jakarta EE 8 as quickly as possible, we're proposing
a compromise that is different than what we would normally do.  I'd
like to make sure this compromise is acceptable to the Specification
Committee so that there are no surprises when we are reviewing the
Jakarta EE 8 specifications for approval.

Since Jakarta EE 8 will be completely compatible with Java EE 8, we've
proposed that, in general, we will *not* be releasing new versions of
the implementations for each API.  We will simply test the existing,
released, implementations that have already passed the Java EE 8 TCKs
using the Jakarta EE 8 TCKs.  (In some cases projects may choose to
release new versions of the implementations, and while that will be
allowed, it will neither be required nor expected.)

That would be simple enough except for one thing...

We need to update all of the javadocs for all of the APIs to use the new
specification names and to use the Eclipse Foundation Specification License.
This will require releasing new versions of (at least) the API jar files
for every API.  The corresponding javadocs will be included in the release
reviews for the specifications.

The specification release reviews will require the specification documents,
which will include theses javadocs, the TCKs, and at least one compatible
implementation.  Again, the compatible implementation will be the existing,
released, implementation that does *not* use these API jar files.

It would seem wrong to release these new API jar files without any testing
whatsoever.  We're proposing that these API jar files be tested by (where
applicable) integrating them with the corresponding standalone implementation
and testing that combination with the corresponding standalone TCK, and/or
integrating that API jar file into GlassFish and using one of the GlassFish
TCK jobs to test that API jar file with its corresponding TCK tests.  Note
that these combinations of API jar files and implementations would *not*, in
general, be released (although a project could choose to do so as long as it
doesn't depend on GlassFish).

Ideally, the combination of API and implementation would be tested and
released, and that's what would be referenced as a Compatible Implementation
for the specification release review.  But we won't do that for this release.
Given the constraints of this release, we believe the above compromise is
acceptable.

Comments?