Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Continue semantic versioningdiscussion...
Thank you, we'll try to discuss that next week at Java2Days when Otavio, Ivar, myself and a few others (at least Red Hat, IBM and Payara are among the speakers) are expected to speak in Sofia.
 
Unfortunately there's been a little glitch with a single-digit build number, but looking at e.g. Jakarta Batch while it was still a JSR https://mvnrepository.com/artifact/javax.batch/javax.batch-api it went directly from "1.0-b07" to "1.0-b13" within less than a week in 2013, so the best way to fix the "bXY" version and also the exact versioning of the spec document seems to do a similar adjustment to "b10", otherwise the version sorting and more severely build systems like Ivy or Gradle offering a "latest-version" dependency resolution would get confused if "1.0.0-b1" was replaced by "1.0.0-b02".
 
Werner
 
 
Gesendet: Montag, 25. November 2019 um 21:39 Uhr
Von: "Bill Shannon" <bill.shannon@xxxxxxxxxx>
An: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>, "Kevin Sutter" <sutter@xxxxxxxxxx>
Cc: jakartaee-platform-dev-bounces@xxxxxxxxxxx
Betreff: Re: [jakartaee-platform-dev] Continue semantic versioningdiscussion...
Ooh, you're right!  Good catch, Kevin!  It should just be "1.0".
 
Kevin Sutter wrote on 11/25/19 7:28 AM:
The only item that doesn't seem right is the Specification Version in your example, Werner.

 jar Specification-Version:  1.0.0.01



The Specification Version should only be a major.minor version number.  No additional "patch" versions would be used to define a Spec Version.

---------------------------------------------------
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:        Bill Shannon <bill.shannon@xxxxxxxxxx>
To:        jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>, Werner Keil <werner.keil@xxxxxxx>
Date:        11/23/2019 20:52
Subject:        [EXTERNAL] Re: [jakartaee-platform-dev] Continue semantic versioningdiscussion...
Sent by:        jakartaee-platform-dev-bounces@xxxxxxxxxxx



Yes, that's correct.

Werner Keil wrote on 11/23/19 9:39 AM:

Bill,

 

Thanks, that pointer is really helpful.

 

Are the versioning rules for all non-final artifacts therefore also applicable to e.g. Jakarta NoSQL and how would you say this should be for the upcoming first „Early Draft“ or „Milestone“ release of NoSQL?

 

Let me Sketch something how I think it could work for JNoSQL/Jakarta NoSQL

(I left the OSGI aspect out for the sake of simplicity)

 

NoSQL:

 

    API_PACKAGE=jakarta.nosql

    IMPL_NAMESPACE=org.eclipse.jnosql

    STANDALONE_IMPL=true

    SPEC_VERSION=1.0

    SPEC_IMPL_VERSION=1.0.0

    IMPL_VERSION=1.0.0

    NEW_SPEC_VERSION=1.0

    SPEC_BUILD=01

    NEW_IMPL_VERSION=1.0

    IMPL_BUILD=01

 

    API jar file:         jakarta.nosql-api.jar

      Maven group ID, artifact ID:   jakarta.nosql:jakarta.nosql-api

      Maven version:      1.0-b01

      jar Extension-Name:     jakarta.nosql

      jar Specification-Version:  1.0.0.01

      jar Implementation-Version: 1.0-b01

 

    Implementation jar file:  jakarta.nosql.jar

      Maven group ID, artifact ID:   org.eclipse.jnosql:jnosql.parent

      Maven version:      1.0-b01

      jar Extension-Name:     jakarta.nosql

      jar Specification-Version:  1.0.0.01

      jar Implementation-Version: 1.0-b01

 

Does that sound about right?

 

Of course the implementation has multiple modules,  I only showed the parent here because it should be applicable to all others in a same way.

 

Thanks,

Werner

 

From: Bill Shannon
Sent: Saturday, November 23, 2019 00:28
To: jakartaee-platform developer discussions
Subject: Re: [jakartaee-platform-dev] Continue semantic versioningdiscussion...

 

As background for this discussion, remember that we're defined many of our versioning rules hereand we've defined compatibility requirements here.  We should use these documents as a starting point as we cover additional cases.

 



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

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



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

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

Back to the top