Skip to main content

[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

 

 

Von: jakartaee-platform-dev-bounces@xxxxxxxxxxx [mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx] Im Auftrag von Emily Jiang
Gesendet: Freitag, 17. Januar 2020 00:28
An: jakartaee-platform developer discussions
Betreff: Re: [jakartaee-platform-dev] version numbers and release qualifiers

 

I have not got that issue. What error did you get? We specify the following without any problem

<!-- https://mvnrepository.com/artifact/org.eclipse.microprofile.fault-tolerance/microprofile-fault-tolerance-api -->
<dependency>
    <groupId>org.eclipse.microprofile.fault-tolerance</groupId>
    <artifactId>microprofile-fault-tolerance-api</artifactId>
    <version>2.0.3-RC1</version>
</dependency>

I might have misunderstood what you meant.

 

Thanks

Emily

 

On Thu, Jan 16, 2020 at 11:03 PM Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:

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

 

Von: jakartaee-platform-dev-bounces@xxxxxxxxxxx [mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx] Im Auftrag von Emily Jiang
Gesendet: Donnerstag, 16. Januar 2020 23:56
An: jakartaee-platform developer discussions
Betreff: Re: [jakartaee-platform-dev] version numbers and release qualifiers

 

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.

 

On Thu, Jan 16, 2020 at 10:35 PM Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:

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



--

Thanks
Emily

_______________________________________________
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



--

Thanks
Emily


_______________________________________________
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


Back to the top