Markus,
The platform Project SHOULD
at least guide the others if they do something on their own,
even if it may have to escalate the ultimate decision to
either or all of These 3 bodies that make binding decisions.
If you check the minutes of
the platform calls there were lots of "decision" making there so this is what Kevin and
others refered to and it is up to the platform committers to
do that at this Point.
Aside from that In the words of Bill Shannon,
let's put this "discussion to bed"... :-)
Werner
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
![cid:image002.png@01D5A160.46F74440]()
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
