The only item in this I have certainty about is that there is no reason for a 1.0.0 package. The CDI spec cannot go backwards to 1.0, and jakarta.enterprise.* still will be referred to in the context of the current spec, so to have that at 1.0.0 and a spec at 3.0 seems like a needlessly pedantic interpretation of semantic versioning.
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.- Semantic
versioning at the Spec level (ie. JPA 2.2 -> 3.0)
- 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.
