| [jakartaee-spec-project-leads] Questions on the intial certification request using a pre-release impl |
We know there is some circular dependency in this process ( "chicken/egg").. e.g. the compatible impl can't be finalized until spec and dependencies are finalized yet the compatible impl is needed to approve the spec in the first place.
So for the Batch 2.0 PR: https://github.com/jakartaee/specifications/pull/238 my thoughts were to:
1. Write up the certification request issue: https://github.com/eclipse-ee4j/batch-api/issues/110 as if I were using the final, v2.0.0 "jbatch" implementation release.
2. Run the staged TCK against a pre-release v2.0.0 identified by source tag (but not maven release)
3. Once the API, spec, and TCK are finalized along with dependencies, release the v2.0.0 "jbatch" implementation.
4. Re-run the TCK against v2.0.0 jbatch impl.
5. Add a note to the certification request issue?
----
Any concerns? Does this seem reproducible enough?
Would it be better to do a milestone release of the jbatch impl, and then write up the certification request issue against this milestone release? Does it matter if the impl isn't using final versions of Jakarta dependencies (if it did, I'd have to wait until the Transaction API is staged). Any rules on whether a compatible impl can use milestone releases?
I'd think 4, 5, above would be more about certifying the jbatch 2.0.0 impl than necessary to finalize the spec/API... which would already have been approved at that point, so maybe that's not necessary or should NOT be done (i.e. don't tamper with the historical record)?
I don't want to go overboard with rigor if this isn't really necessary and in line with what other specs are doing, but trying to be transparent and not sweep anything under the rug either.
Thanks,
------------------------------------------------------
Scott Kurz
WebSphere Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------