| Re: [jakartaee-platform-dev] version numbers and release qualifiers |
Well it seems both Apache (in some Projects) and MicroProfile (in most projects) use at least "m" & "rc" quite a bit. The question of "mr" was discussed a while ago in the Specification Committee and similar to "edr" that was most common in JCP times. Up until the "Luna" release train https://www.eclipse.org/downloads/packages/release/luna the term for this was "sr" (Service Release) which also did work for sorting ("M", "RC", "R" although that did not use the qualifier and "SR") After that release some variations like "1" or "1A" were used for updates, but since the quarterly release cycle after 2018 there are no more Service Releases, but the "M" and "RC" still get used for each release. Werner From: Mark Struberg 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. LieGrue, strub > 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 https://jcp.org/en/jsr/stage, 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 > https://jcp.org/en/procedures/jcp2_11). 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 > 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 |