Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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

Back to the top