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

Back in the late days of Maven-1/early Maven2 we introduced some alphanumeric ordering.
But this is not applied everywhere. Plus it is inconsistent. So I'd rather avoid it alltogether.

Some people learned that the hard way. Ask JBoss why they use CR1 and not RC1 for Release Candidate?
The answer is that for some plugins a standard sort gets applied. And RC1 would be after MR1, because R comes after M. But C comes before M.
And we didn't yet even start to discuss whether nn-MR stands for Maintenance Release (after releae nn) or Milestone Release (chronoligically before release nn).

Thus I'd also suggest to keep it purely numeric if possible.


> Am 21.01.2020 um 23:39 schrieb Piotr Żygieło <piotr@xxxxxxxxxx>:
> On Tue, 21 Jan 2020 at 21:54, Werner Keil <werner.keil@xxxxxxx> wrote:
>> EDR was used by the JCP for its Early Draft stage, see, similar for Public Review, Proposed Final Draft and in some cases maybe also Maintenance Releases.
> JCP does not specify version scheme used by Specification
> deliverables, (at least I can't find it at
> So using EDR, PR or MREL in
> versions is not mandatory I think.
> Obvious general observation: As long as deliverables are clickable
> elements, that one (Client) has to navigate on page to download given
> pdf, zip, jar - you* are free to use whatever name you like. You don't
> have to produce maven-coordinated artifacts. You don't have to use
> maven repository for distribution. Even if you do - you don't have to
> follow maven way. You might release against it.
> Just consider, that it might not work as you assume.
> [People of] Maven decided to support pre-release "a", "b", "m" & "rc"
> qualifiers, and you can use that in your versioning but you don't have
> to. You can map your internal stages to supported qualifiers, or to
> encode them in numbers only, or map internal versions to completely
> different but maven-compatible public ones. Options seem to be
> unlimited.
> If you don't like it and you have better plan - raise to maven, and
> they will evaluate and implement such changes. And repositories and
> tools will follow.
> * - with "you" not targeting anyone particular
> But that's what I think. And I might be wrong.
> -- 
> Piotrek
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top