[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] version numbers and release qualifiers
|
My recommendation would be that if you
need to publish
individual builds (and most projects probably don't), then use -b#.
If you need to publish both builds and beta releases, then use
milestones for beta releases. It's not perfect, but it's a
compromise.
I would never recommend mixing alphabetic qualifiers and numeric
qualifiers, or a fourth numeric version component.
But as usual, these are all recommendations. If you feel that your
project has needs that are different than other projects, you can
use a scheme that makes sense for your project. At least for
implementation projects. The specification committee or platform
project may place requirements on API jar files and TCK zip files,
for example.
Markus KARG wrote on 1/18/20 6:47 AM:
Emily,
the
problem is described by https://maven.apache.org/pom.html#Version_Order_Specification
in
this section:
§ if
the prefix is the same, then compare the token:
§ Numeric
tokens have the natural order.
§ Non-numeric
("qualifiers") tokens have the alphabetical order,
except
for the following tokens which come first in this order:
"alpha"
< "beta"
< "milestone"
< "rc"
= "cr"
< "snapshot"
< "" = "final"
= "ga"
< "sp"
§ the
"alpha",
"beta"
and "milestone"
qualifiers can respectively be shortened to "a", "b"
and "m" when directly followed by a number.
§ else
".qualifier"
< "-qualifier"
< "-number"
< ".number"
Problem
1: This means that the proposed "-b"
for "build" would be interpreted as "beta",
which is not the same (just as Bill commented).
Problem
2: When using version ranges (like [1, 2))
then it is not trivial to understand which one is
the actually highest version number to resolve to: 1.1-8
(natural order) or 1.1-b7
(alphanumeric order)?
That's
the reason why I would kindly ask to only use the Maven best
practice and no invent anything new. In particular, to not
use "-b"
for anything else but "beta", while other builds
simply are "-number"
(without any letter).
HTH
-Markus
I have not got that issue. What error
did you get? We specify the following without any problem
I might have misunderstood what you
meant.
Maven
is able to find latest builds (i. e. 1.1.1-2
is a later build than 1.1.1-1) only if the build is
all-numbers. Using ranges like [1.0; 1.1)
will care for that build numbers, IMHO not only for
the major, minor and patch numbers. Maven cannot do
that if there is a letter in the build number,
because it treats that as a non-buildnumber but as a
"qualifier" (See Maven Version Syntax description).
"qualifiers" are not necessarily integral. For
example Maven has no clue if -rc1 is later or
earlier that -rc01.
-Markus
The
format of x.x.y where x must be a number and y can
contain letters, e.g. 2.0.3-RC1.
What
kind of version range do you use? if you use [2.0,
2.1). 2.0.3-RC1 will be in the range.
Pleas
stay compatible with Maven best practices. In
particular, build
numbers must not have letters in Maven versions
because they would break the
version range feature.
-Markus
-----Ursprüngliche Nachricht-----
Von: jakartaee-platform-dev-bounces@xxxxxxxxxxx
[mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Bill
Shannon
Gesendet: Mittwoch, 15. Januar 2020 22:30
An: jakartaee-platform developer discussions
Betreff: [jakartaee-platform-dev] version numbers
and release qualifiers
I've updated our versioning spec [1] to reflect
our recent decision to
use dot-dot version numbers for API jar files,
e.g., of the form x.0.0.
Please let me know if you see any mistakes,
especially in the OSGi rules.
Also, we need to decide what release qualifiers to
recommend. So far
we've been recommending these (where
<number> is a sequence number):
-b<number> - build
-m<number> - milestone
-rc<number> - release candidate
The pre-defined qualifier is "-SNAPSHOT", which
raises the question as
to whether our qualifiers should be upper case as
well. I've mostly
seen lower case being used, which is why the
document recommends lower
case, but I can see an argument for all qualifiers
being upper case.
Comments?
Once we come to a decision on this I'd like to
send it to the PMC and
ask them to "bless" it as the recommendation for
all EE4J and Jakarta EE
projects.
Thanks.
[1] https://wiki.eclipse.org/JakartaEE_Maven_Versioning_Rules
_______________________________________________
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
