[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-spec-project-leads] Questions on the intial certification request using a pre-release impl
|
The only part of this I don't agree on is any need for a final version of the CI. Any public version should be fine.
Scott Kurz,
I think your proposed
process sounds very reasonable and consistent with what we did in Jakarta
EE 8. Wherever possible, each individual Specification Project should
be preparing their individual TCKs and Compatible Impls, and doing the
"final" verification testing. You should be using the "final"
versions of the APIs, TCKs, and CIs per the staging processes. None
of these artifacts should be made available via Maven until the ballots
are completed.
Each of these
individual TCKs feed into the Platform TCK. I look at that as a separate
process. That is, the Batch Spec PR should not be required to wait
until the Platfrom Spec PR is complete before initiating their ballot.
If there are some tweaks that need to be done to the Batch TCK in
order to merge with the Platform TCK (post the Batch PR ballot), then these
should be accomplished via a third digit update (ie. 2.0.x of the TCK).
Hope this helps!
And, thanks for asking these questions. I'm sure there are
others with similar thoughts...
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From:
"Scott
Kurz" <skurz@xxxxxxxxxx>
To:
JakartaEE
Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>
Date:
08/04/2020
09:09
Subject:
[EXTERNAL]
Re: [jakartaee-spec-project-leads] Questions on the intial certification
request using a pre-release impl
Sent
by: jakartaee-spec-project-leads-bounces@xxxxxxxxxxx
Thanks Scott for replying.
I had only been discussing the pre-release compatible impl, not the Batch
TCK.
But I did have something like you mentioned in mind if were any TCK doc
PRs do come in: that we'd accumulate them, and then do one final certification
re-run at the end.
------------------------------------------------------
Scott Kurz
WebSphere Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------
Scott
Marlow ---08/04/2020 09:59:13 AM---Thanks Scott for raising this. From
a Standalone TCK staging perspective, Jakarta Batch does contro
From: Scott Marlow <smarlow@xxxxxxxxxx>
To: JakartaEE Spec Project Leadership
discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>
Date: 08/04/2020 09:59 AM
Subject: [EXTERNAL] Re: [jakartaee-spec-project-leads]
Questions on the intial certification request using a pre-release impl
Sent by: jakartaee-spec-project-leads-bounces@xxxxxxxxxxx
Thanks Scott for raising this. From a Standalone TCK staging perspective,
Jakarta Batch does control its own standalone TCK, however, from a process
point of view, I think it should be the same as others.
After feedback (regarding contributors needing more time to review TCK
documentation than a weekend) yesterday on the Jakartaee-tck mailing
list, I do want to give some suggestions for Jakarta Batch Standalone TCK,
as well as all of the others.
With regard to Standalone TCK deliverables, we can easily stage new builds
of each Standalone TCKs, however we can only promote a specific versioned
Standalone TCK once (with the last promoted TCK version targeted for EE
9 final release).
So from a TCK perspective, I propose that contributors review TCK documentation
and create pull requests over the next N days, where N is to be discussed
further (perhaps N could be 10 calendar days including non-working days
or some other duration yet to be discussed).
Whatever N is for the final date to create TCK documentation pull requests
by, each SPEC API ballot could work off of an initial promoted TCK (e.g.
assuming no TCK test failures and SPEC API lead approves current TCK doc).
If subsequent TCK documentation pull requests come in after the SPEC API
ballot, the SPEC lead (or TCK team) could push a new staged Standalone
TCK update that could then be promoted with the updated TCK documentation.
Would ^ help with the chicken + egg issue?
Scott
On Tue, Aug 4, 2020 at 8:53 AM Scott Kurz <skurz@xxxxxxxxxx>
wrote:
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/238my thoughts were to:
1. Write up the certification request issue: https://github.com/eclipse-ee4j/batch-api/issues/110as 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
--------------------------------------------------------
_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads
_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads
_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads