Re: [jakarta.ee-spec.committee] [jakarta.ee-steering] Subsequent release

["Kevin Sutter" <sutter@xxxxxxxxxx>]

Paul,
What about the
honor system?  We're already self-certifying, so why not take that
a step further?  Once a product certifies to Jakarta EE, that certification
is good for 12 months.  We will assume that the product will continue
to run the TCK while they are producing their service releases and/or continuous
delivery releases.  If a product has some major function improvement,
they are welcome to submit new certification results at any time before
the 12 month window expires (and the clock restarts).  This approach
would allow each product to decide the proper cadence for submitting new
results. 

I'm just thinking
about the processes involved here...  If we require certification
requests with each minor update and we start to produce multiple Jakarta
EE releases, the number of Certification Requests and TCK Results to create
and review could get to be a lot of work.  For both the certified
product as well as the review process.

I'm also curious
on the Certification web page...  Are we going to list every version
of every product certified?  For example, Wildfly just sumitted CRs
for their 18.0 version.  Are we going to list both 17.x and 18.x versions
on the website?  Just the first?  Just the latest?  Or,
maybe we need to adjust the main web page to only list the products and
then click to find the versions that are certified?  Something simple
like "Version: <multiple>", where <multiple> is a
hot link to the versions certified?  We'll have to figure something
out since listing all product versions will get cumbersome.


---------------------------------------------------
Kevin Sutter 
STSM, MicroProfile and Jakarta EE architect
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter



From:
       Paul
Buck <paul.buck@xxxxxxxxxxxxxxxxxxxxxx>
To:
       Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Cc:
       Kevin
Sutter <sutter@xxxxxxxxxx>, Jakarta EE Steering Committee <jakarta.ee-steering@xxxxxxxxxxx>
Date:
       10/07/2019
04:03 PM
Subject:
       [EXTERNAL]
Re: [jakarta.ee-spec.committee] [jakarta.ee-steering] Subsequent releases
of a Compatible Implementation

---

How about an approach where if a product
is doing semantic versioning the testing and providing a link to results
is required for minor and major releases. Also for service releases where
there is very real possibility that something that has gone in to the service
release could break compatibility, run the TCK and send the link to the
results.

For products that are doing a continuously
delivery release train model then pick a time window to run the TCK, no
fewer times than twice in 12 months. Also for continuous update model
where there is very real possibility that something that has gone in to
the update could break compatibility, run the TCK and send the link to
the results.



On Fri, Oct 4, 2019 at 2:54 PM Bill Shannon
<bill.shannon@xxxxxxxxxx>
wrote:
I think this is really an issue of what
the Eclipse TCK license requires, which means it's an issue for Eclipse. 
Eclipse might decide to interpret the requirements such that, as long as
the TCK results are updated with each release of the Product, and the link
to the results is still valid, the link to the results doesn't need to
be resent.

But if the TCK results are for release 8.9.0.0.0, I don't think you can
claim that release 8.9.0.0.13 is compatible (for example).

Note that the Eclipse TCK license requirements are different than the Java
EE TCK license requirements in this area.

Kevin Sutter wrote on 10/4/19 6:55 AM:
I suppose this
requires a discussion with the Specification Committee?  I don't think
this is a Steering Committee question...

For example, what does a minor release mean when you release every four
weeks like Open Liberty?  Our numbering scheme is yy.0.0.nn, where
yy equals year and nn equals 4-week iteration number.  So, we never
have a "minor release" in that classic sense.  And, although
we will be running the CTS bucket continuously, I don't see any sense in
doing a CR and email every 4 weeks...  

---------------------------------------------------
Kevin Sutter 
STSM, MicroProfile and Jakarta EE architect
e-mail:  sutter@xxxxxxxxxx    Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter



From:        "Steve
Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
To:        Bill
Shannon <bill.shannon@xxxxxxxxxx>,
Jakarta EE Steering Committee <jakarta.ee-steering@xxxxxxxxxxx>
Date:        10/04/2019
04:01 AM
Subject:        [EXTERNAL]
Re: [jakarta.ee-steering] Subsequent releases of a Compatible Implementation
Sent by:        jakarta.ee-steering-bounces@xxxxxxxxxxx

---

OK makes sense.

 

From:Bill Shannon <bill.shannon@xxxxxxxxxx>
Sent: 03 October 2019 21:18
To: Jakarta EE Steering Committee <jakarta.ee-steering@xxxxxxxxxxx>; Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-steering] Subsequent releases of a Compatible Implementation

 

Yes, I would expect a certification request for every minor release, along with email to tck@xxxxxxxxxxx.

Steve Millidge (Payara) wrote on 10/3/19 8:20 AM:

Hi All,

 

Not sure if this is a question for the steering committee or spec committee. Once we have a achieved certification as a compatible implementation how does it work wrt subsequent minor releases. I am assuming we make a certification request for each minor release? I read as much of the process and guidance as I can but can’t find the answer.

 

Steve Millidge

Founder
Payara Services Ltd - Open Source Enterprise Software & Support
US: +1 415 523 0175 |UK: +44 207 754 0481 |M: +44 07809 703032

----------------------------------------------------------------------------------------------------------------------

Payara Services Limited, Registered office: Unit 11, Malvern Hills Science Park, Geraldine Road, Malvern, WR14 3SZ
Registered in England and Wales: 09998946 | VAT: GB 193854467 | www.payara.fish| info@xxxxxxxxxxx| @Payara_Fish

If at any time you would like to unsubscribe from Payara communications, simply respond to this email with 'Unsubscribe' in the title, or instantly unsubscribe from all types of communication here.

 

 

_______________________________________________

jakarta.ee-steering mailing list

jakarta.ee-steering@xxxxxxxxxxx

To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://www.eclipse.org/mailman/listinfo/jakarta.ee-steering

 _______________________________________________
jakarta.ee-steering mailing list
jakarta.ee-steering@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-steering

_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee