Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Continue semantic versioning discussion...
+1 on not to add -RELEASE or -Final to keep the number simple.
I agree that going back to 1.0.0 for the package version is theoretically correct but perhaps not very practical. Since we are on the new package, we are free to set the starting point. I think we still need to decide whether to increase all major version on each package starting with jakarta or take the liberty to stick with the old version as our new base, detailed below.

Option 1: Keep the old version, so javax.enterprise.decorator; version=2.0 -> jakarta.enterprise.decorate;version=2.0
Option 2: Increase the major version, so javax.enterprise.decorator; version=2.0 -> jakarta.enterprise.decorate;version=3.0 //If we do this, we will need to reset the 2nd digit to 0 and increase the first digit by 1.

I think either option is ok, because we are just deciding the starting number. Option 1 is much simpler.

As for the spec version, I think we should increase the major version to signal new binary incompatible changes being introduced.


My 2 cents.
Emily



On Wed, Nov 20, 2019 at 9:57 AM Otavio Santana <otaviopolianasantana@xxxxxxxxx> wrote:
Thank you Tibor for explaining it.

On Wed, Nov 20, 2019 at 1:07 AM Tibor Digana <tibordigana@xxxxxxxxxx> wrote:
I am a Maven developer and I can tell you that the Maven comes with the best practices for the users.

You do not have to tell it twice that you are in the release repo if you deploy 4.0.3-RELEASE.
If it is not 4.0.3-SNAPSHOT, then we know that it can be only release repo.
You do not need the qualifier  RELEASE and you can simply deploy 4.0.3 because we know that the number is release in the release repo.

We know that the release versions are prohibited from overriding it. But the snapshots are not prohibited to overwrite and this is the main difference.

If you want the user to give it a try with a kind of Alpha or Beta release version, e.g. 4.0.3-RC1, it is obvious that the final version will be 4.0.3 but yet you may want to try the RC1 and you can help with reporting a blocker bug in Jira.
So having the 4.0.3-GA or 4.0.4-Final is unnecessary notation to tell that it is 4.0.3 in real and that there won't be any release candidate for it anymore.

Simplicity over bureaucracy!

T

On Wed, Nov 20, 2019 at 12:02 AM Werner Keil <werner.keil@xxxxxxx> wrote:

Hi Kevin,

 

That's a a very good Point, thanks for bringing it up.

One more aspect I would like to Mention is, how a qualifier like "RELEASE" or "GA" fits into the semantic versioning scheme?

 

One example of practicing that, while many other Jakarta EE 8 specs avoided using them would be Servlet:

https://github.com/eclipse-ee4j/servlet-api/releases/tag/4.0.3-RELEASE

 

Especially in Sonatype/Mavencentral I learned, that some qualifiers also affect the way the latest version is sorted and displayed (ie. 4.0.3-RELEASE > 4.0.3)

 

We recently had a few discussions around using qualifiers like "RC1" or "M1" for incubating specs like NoSQL, but especially towards new releases they could also apply to the final ones.

 

Werner

 

From: Kevin Sutter
Sent: Tuesday, November 19, 2019 21:44
To: jakartaee-platform developer discussions
Subject: [jakartaee-platform-dev] Continue semantic versioning discussion...

 

Hi,
At the end of our Platform Dev call this morning, we started to discuss the versioning of the Jakarta Component specs due to the jakarta namespace update.  As an example, with the jakarta package rename, should the next version of CDI be 2.x or 3.0?  This was initially brought up as part of this thread:
https://www.eclipse.org/lists/jakartaee-platform-dev/msg00862.html

The initial response on the call was "Yes", the major version of the CDI Spec must increase with the change in package names.

But, as we continued talking, it was clear there were two aspects (at least) of semantic versioning that come into play.

  1. Semantic versioning at the Spec level (ie. JPA 2.2 -> 3.0)
  1. Semantic versioning at the Package level (ie. javax.persistence.* -> jakarta.persistence.*)


1.  Spec level versioning.  I'm going to assume that the initial response is still accurate and we expect the individual Jakarta components to increase the major version of their Specs.  Sticking with the JPA example, this would require a new entry in the maven repo for a 3.0 release, which would have the following coordinates:

<!-- https://mvnrepository.com/artifact/jakarta.persistence/jakarta.persistence-api-->
<dependency>
    <groupId>jakarta.persistence</groupId>
    <artifactId>jakarta.persistence-api</artifactId>
    <version>3.0.0</version>
</dependency>

This usage would allow proper dependency management at the macro level -- at the Spec and API level.

2.  Package level versioning.  This is what BJ brought up at the end of the call.  As an example, look at the MANIFEST.MF for JPA 2.2.3:

Export-Package: javax.persistence.metamodel;version="2.2.3",javax.persis
 tence;uses:="javax.persistence.criteria,javax.persistence.metamodel,jav
 ax.persistence.spi";version="2.2.3",javax.persistence.criteria;uses:="j
 avax.persistence,javax.persistence.metamodel";version="2.2.3",javax.per
 sistence.spi;uses:="javax.persistence,javax.sql";version="2.2.3"

Since we're moving from javax.persistence.* to jakarta.persistence.*, this is technically a new API package and, thus, should start over at 1.0.0.  A few questions come to mind here...

  • If we claim we want to follow semantic versioning, does it require us to recognize this name change and start over at "1.0.0" with the package export?  Or, can we decide that this change from javax to jakarta is just a continuation of the old package and use "3.0.0" for the jakarta.persistence.* packages?
  • If it's decided that the jakarta.persistence.* package rename requires a "1.0.0", does it make sense to have different package versions from the external Spec/API version?  In this case, the packages would be exported as "1.0.0", but the Spec would be at "3.0".
  • Do we even care?  Do any of the Jakarta components currently import packages with specific version numbers?  The JPA MANIFEST just imports the package names with no versions.  I know this comes into play with an OSGI-based system (we use both export and import packages with versions in Open Liberty, for example).  But, do we need or want to incorporate that level of dependency mgmt on everyone using Jakarta EE?


I have my thoughts on what we should do, but let's start with the discussion first.  Thanks.

---------------------------------------------------
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

 

_______________________________________________
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


--
Otávio Santana
_______________________________________________
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


--
Thanks
Emily

Back to the top