Markus is correct the platform project has no special powers over EE4J projects in the same way that the Jakarta EE working group has no special powers. A project’s committers could go off and do
their own thing. However there is an inherent tension built into the governance in that to be a “Jakarta” specification a project needs to gain approval by the specification committee of the Jakarta EE working group and follow the EFSP. To make it into the
Full Profile or Web Profile of Jakarta EE a project’s WG approved specification must be approved for inclusion by the platform project. The platform project has full autonomy same as any other project. So there are checks and balances to maintain a coherent
platform. These checks and balances require discussion and compromise to be satisfactory to all as it should be.
Therefore the platform project is within it’s rights to include MUST rules for projects that wish to be included in the Full or Web Profile including rules for versioning etc. to maintain the coherent
nature of the platform. Therefore the platform project MUST not use SHOULD for all its recommendations.
Kudos to the Eclipse Foundation for creating this governance structure.
Steve
From: jakartaee-platform-dev-bounces@xxxxxxxxxxx <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
On Behalf Of Markus KARG
Sent: 22 November 2019 17:18
To: 'jakartaee-platform developer discussions' <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Continue semanticversioning discussion...
Werner,
in an attempt to reach a concencus it might be beneficial if we all at least try to understand each other's position instead of pointing out typos or grammar. Thanks.
By "proposals to that committees and projects" the term "projects" means the EE4J projects found on this page
https://projects.eclipse.org/projects/ee4j
in the box "Related Projects".
The Jakarta EE platform project has no special powers about other Jakarta EE specifications, as (as already said) they are independent and can (mostly) all used without each other. It might be beneficial
to propose common rules ("SHOULD"), but there is no actual need to enforce it ("MUST"). Hence my plea to use exact terms what the platform project wants to propose actually and to whom. In the end we all need to be sure what we MAY, MUST, COULD, SHOULD etc.
do. I cannot see what is "overkill" in being absolutely clear about the intention of a proposed rule.
Regards
-Markus
Markus,
Most of that is hard to understand and some does not really make much sense.
What is correct are the Statements About the spec Committee, PMC and steering Committee have the ultimate say, but since the platform Project holds together all of the individual Projects it shall at least have some say
even if via those who are represented in multiple of These anyway.
"proposals to that committees and projects".
What do you mean with that aside from not being a proper sentence?
These committees see above, but what Projects (plural) do you mean?
At least for the Projects under the Control of Eclipse Foundation / EE4J there should be a Consensus and Consistency instead of having one e.g. add a qualifier like "RELEASE", the next one calling it
"GA" and others avoiding that.
As for 2) ignoring it, most of those Terms are often in the License agrements where applicable anyway, but for technical discussions even if some in certain committees and projects probably have a stronger
legal than technical Background, throwing MUST and MUST NOT around in emails feels like an overkill.
Werner
Kevin,
with all due respect, I like to amend your proposal by two comments to be clear what you talk about.
(1) According to the EF rules, a decision about "components" cannot be decided by *the platform project* as what you call "components" actually are not "sub-parts" of the platform project, but are standalone
EF projects and standalone specifications (they would be existing even if Jakarta EE would die); so only the PMC, spec committee and steering committee have the power for decide about these projects (and certainly the committers of those projects). Possibly
you meant eactly that by "until Tuesday's meeting", but it is not clear. So let's clearly call the content of your email "proposals to that committees and projects".
(2) We should start to use the exact terms MUST, MUST NOT and SHOULD instead of "will need to" and similar phrases. As we all are used to those terms, really everybody knows exactly the difference between
an absolute force and a guiding advice. With respect to the independence of the reference technologies and projects, we should abstain from using MUST and MUST NOT until there is an absolute legal, technical or organizational limit that has to be respected.
In all cases what we discuss in the platform API project should be really just guiding advice, so we should use the term SHOULD always.
Thanks
-Markus
In the words of Bill Shannon, let's put this "discussion to bed"... :-)
Thanks for the discussion. I also spoke with BJ (he brought up the item about the package versioning). He agreed that it was not necessary to reset the package version to 1.0.0.
We can start the package versioning at any number. His main interest is that we continue to increment the versions according to the rules of semantic versioning. And, since we have stated our interest in that goal since the start, I think we're in good
shape.
Based on all of this input, here's the proposal. I won't claim it's a "decision" until Tuesday's meeting since it was left over agenda item.
1. Spec level versioning. Due to the change from javax.* to jakarta.*, all of the individual
Jakarta components will need to increase their major version for the Spec (x.y) and API (x.y.z).
Using JPA as an example, this would require a new entry in the maven repo for a 3.0.0 release of the API, 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>
2. Package level versioning. The exported package names in the MANIFEST.MF should also be increased to the new major version.
Again, using JPA as an example, the MANIFEST.MF for JPA 3.0.0 would look something like this:
Export-Package: jakarta.persistence.metamodel;version="3.0.0",jakarta.persis
tence;uses:="jakarta.persistence.criteria,jakarta.persistence.metamodel,jav
ax.persistence.spi";version="3.0.0",jakarta.persistence.criteria;uses:="j
akarta.persistence,jakarta.persistence.metamodel";version="3.0.0",jakarta.per
sistence.spi;uses:="jakarta.persistence,javax.sql";version="3.0.0"
---------------------------------------------------
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: "Kevin Sutter" <sutter@xxxxxxxxxx>
To: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
Date: 11/19/2019 14:44
Subject: [EXTERNAL] [jakartaee-platform-dev] Continue semantic versioning discussion...
Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
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.
---------------------------------------------------
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