User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1
This was discussed in the Spec. committee meeting. We concluded
that it is okay to to do a single PR as follows:
Original TCK line(s) remains as is. Add a sub-bullet that
indicates that JDK 11 support is added (rather than JDK 8 and JDK
11). In my example, I'd change it to the following:
Jakarta Connectors 2.0 TCK(sig, sha, pub)
2.0.1 TCK add support for JDK 11 (sig, sha, pub)
To Scott Marlow's question about Excludes -- there are already
some new excludes in a small number of these TCKs. This was
discussed as well. It seemed to be consensus that new excludes
should just be added to the "dot, dot next" release. We do not
need to create patches for previous versions. To generalize, if
there are excludes added, they would always go to the latest
version of any TCK release version (i.e. 2.0.0 excludes go into
2.0.1. Additional excludes, even if found in 2.0.0 would go into
2.0.2 (and not be added to 2.0.1+)). We would always encourage
implementations to use the latest TCK but if they complete their
work with a previous TCK, that is valid -- even if newer versions
have already been approved.
Additionally, it was noted that general service release checklist
and procedures should be enhanced -- for example a small number of
service releases have also made correction changes to other
elements so having a written outline for mentors to follow will be
beneficial.
For the change with the JDK11 TCK updates described here, I will
reply with the PR ID, once it's ready for review.
Cheers,
-- Ed
On 4/21/2021 7:27 AM, Scott Stark
wrote:
I thought that challenges had to apply to only the
latest TCK. If the 2.0.0 TCK challenge does not also apply to
the 2.0.1 release, then theoretically they can certify using
that. We cannot be patching arbitrary past TCK versions.
On Wed, Apr 21, 2021 at 8:04
AM Scott Marlow <smarlow@xxxxxxxxxx> wrote:
On 4/19/21 3:03 PM, Ed Bratt wrote:
Hi,
I don't think we finalized how to update the Spec.
pages for the service releases needed to coincide with
the Jakarta EE 9.1 release. If we have and I'm just not
recalling, please point me at the details so I can
follow the designated procedure.
All the component TCKs that are produced from Jakarta
EE TCK project (see [1] below) are updated to include
instructions and signature test files for JDK 11. The
Spec. pages for each of these need to be updated to add
link to the updated service release TCK.
I think a reasonable mechanism would be to simply add
the service release TCK link as a second line
I have a related question, if we get a TCK challenge to
exclude (#1) a test in the Connectors 2.0.1 TCK and a
challenge to also exclude (#2) a test in the Connectors
2.0.0 TCK, what would we do?
1. Release Connectors 2.0.2 TCK with both excludes #1 +
#2 (both generated from the Platform TCK 9.1.x branch).
2. Release Connectors 2.0.2 TCK with both excludes #1
(generated from the Platform TCK 9.1.x branch) and release
Connectors 2.0.3 TCK with excludes #2 (generated from the
Platform TCK 9.0.x branch).
I regret that I cannot make the meeting today.
Scott
(each of sig, sha, and pub would be links to the
final TCK location/details.) (We could add JDK 8 to the
original line, just to clarify for future readers if we
think that's helpful.) I would avoid just replacing the
links to the original TCK since those remain valid and
we don't know if anyone is currently working with those.
I don't think this requires distribution of mentors
if we agree with a template for the proposed change but
a PR approver might be useful to avoid stupid errors.
Hopefully, with whatever we finalize, this might be
feasible in a single PR that updates all the Specs that
are impacted [1] in this way.
Seems like this needs, at the least a general
thumbs-up from the committee. (Or, if this is already
decided, just correct me so we can follow the correct
path.)
-- Ed
[1] -- Stand-alone specification TCKs that are
produced by Jakarta EE Platform TCK project:
Component Spec. TCK service releases (If not
already assigned, the remaining could be handled in
a single PR):
Annotations
Authentication
Authorization
Concurrency
Connector
_expression_ Language
JSONB
JSONP (Already assigned mentor)
Messaging
Persistence
RESTful Web Services
Security
Server Faces
Server Pages
Servlet
SOAP with Attachments (Already assigned mentor)
Standard Tag Library
Transactions
WebSocket
XML Web Services (Already assigned mentor)
[2] Following will need to be adjusted to point to the
Jakarta EE 9.1 TCK (along with Platform and Web
Profile). My recommendation would be that these be
updated in the same PR that updates the Platform and Web
Profile details using the same template as is agreed
upon, with the previous list.