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