A counter recommendation could be to not use alphanumeric qualifiers at all, which effectively means, to not publish milestones, betas, rc etc. but simply publish nightly build snapshots in Eclipse Repo and final releases in Maven Central. Ther actually is no need to find pre-releases in Maven Central as typical users only care for the final result and bug fixes (hence use ranges), while all others can explicitly pick particular builds from Eclipse Repo (hence don't use ranges). -Markus Von: Bill Shannon [mailto:bill.shannon@xxxxxxxxxx]
Gesendet: Sonntag, 19. Januar 2020 02:50
An: jakartaee-platform developer discussions; Markus KARG
Betreff: 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
|
