Let me follow-up and answer my own question…
(Thanks to comments from Scott M., Scott S., and Emily for helping me sort through this.)
I was overcomplicating and reading too much into the required process.
All I needed to do was follow the instructions at the end of:
https://jakarta.ee/committees/specification/tckprocess/ in section:
Process for releasing a point revision of a TCK
I will need to open an issue in the spec repo to get the TCK 2.1.1 JAR signed and copied in the right place but I can do that without further help from the list here.
(I closed my PR 507).
Thanks,
Scott Kurz
From: jakarta.ee-spec <jakarta.ee-spec-bounces@xxxxxxxxxxx>
On Behalf Of Scott Kurz
Sent: Wednesday, June 8, 2022 10:25 AM
To: jakarta.ee-spec@xxxxxxxxxxx
Subject: [EXTERNAL] [jakarta.ee-spec] Jakarta Batch PR for Service Release 2.1.1 for TCK challenges (plus process question)
This Message Is From an External Sender
|
This message came from outside your organization.
|
|
|
To respond to a couple Jakarta Batch TCK challenges, I staged a TCK v 2.1.1 update and prepared PR:
https://github.com/jakartaee/specifications/pull/507
and service release record: https://projects.eclipse.org/projects/ee4j.batch/releases/2.1.1
One thing I’m unclear on though, even after reading:
https://jakarta.ee/committees/specification/operations/#creating_a_final_service_release_specification
and browsing this list is what the requirements are for the api & spec artifacts.
I don’t think it’s helping anyone to release a 2.1.1 API artifact right now, and maybe confusing. If someone bothers to investigate “what’s the difference?” and the answer is “nothing, it’s just to fit
into a complicated spec process”, is that where we want to be? But .. say we did find a very minor bug in the API later on. At that point would we have to do a 2.1.2 service release record (per the Eclipse release project) and would it then be weird for
the API version to jump from 2.1.0 -> 2.1.2? Has this been considered before?
As far as the CCR itself, I’m not planning on creating a new one. Rather I’m thinking I’ll let the original issue of jbatch certified against TCK v2.1.0 remain, while adding a note to the certification issue
that the implementation has been run informally against the new v2.1.1 TCK
---
On top of this there is an altogether separate point I need to eventually raise which is that, following Scott Marlow’s advice (https://github.com/eclipse-ee4j/batch-tck/issues/49#issuecomment-1145335955),
I actually modified the challenged test rather than simply excluding it. We could oversimplify and say that before the test expected behavior A1, and now it accepts either A1 OR A2. Ideally this would be raised as an update/clarification to the TCK process
but I’m struggling some to put it into words, so for now just mentioning that this has come up.
Thanks,
Scott Kurz