Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Message-ID: <5257BA1F.4020702@douma.nu>
Date: Fri, 11 Oct 2013 10:43:11 +0200
From: Ate Douma <ate@douma.nu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was:
 [DISCUSS]
 Putting several unmaintained components to dormant]
References: 
 <CAB917RLfxx3peR30HsM4dWQ04EXrzZ_KoPGZAiccd6oFjHd5Sg@mail.gmail.com>
 <CAPCjjnFvhLbyZvNoejaXSjUQzVay3BxHFn17XD+xArHOzZZMMQ@mail.gmail.com>
 <l34elo$20p$1@ger.gmane.org>
 <CACZkXPw-VtbDJD9Dzs5vo7_vbfSdeFsCpNZ4SHQ856tqj_yuyQ@mail.gmail.com>
 <CAEQx=xkK17thM2-4Z+6vkB9b8FKmBfezTf5dGmU8mHndm8ohuA@mail.gmail.com>
 <5256735D.8090507@douma.nu> <l35une$1d7$1@ger.gmane.org>
 <635E8419-B316-4E95-8390-45B9065EBC82@gmail.com> <52568ECB.6040608@douma.nu>
 <CACZkXPzHCHnq+M7bF1pcyZGJinUYJLHK3KRucd8g9_gRAuX9hw@mail.gmail.com>
 <CALznzY7Zn_n3h8mhh2MEV_-nwYODWi99F5bpLWLHZcH3E4diRw@mail.gmail.com>
 <5256AADF.8010306@douma.nu>
 <CALznzY7OFb3d1BQ8+pOJ-L8nZN8p=Ejne3HNUprJjSziJ=1b6A@mail.gmail.com>
In-Reply-To: 
 <CALznzY7OFb3d1BQ8+pOJ-L8nZN8p=Ejne3HNUprJjSziJ=1b6A@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 10/10/2013 03:31 PM, James Carman wrote:
> We definitely need to make sure our naming scheme will work with maven
> properly.  Hopefully commons-foo:1.0 would supercede
> commons-foo:1.0-M1.  Again, I really don't care what we call it, as
> long as we manage expectations and don't dork up maven.

Since Maven 3+ there is now a reasonable and predictable handling of such 
versioning, including doing 'the right thing' for the commons-foo:1.0-M1 example.

See [1] (which is an old wiki proposal which since has been implemented) and [2] 
for the exact rules, which I'm copying below for convenience.

 From [2]:

   Features:

   - mixing of '-' (dash) and '.' (dot) separators,
   - transition between characters and digits also constitutes a separator: 
1.0alpha1 => [1, 0, alpha, 1]
   - unlimited number of version components,
   - version components in the text can be digits or strings,
   - strings are checked for well-known qualifiers and the qualifier ordering is 
used for version ordering. Well-known qualifiers (case insensitive) are:
       - snapshot
       - alpha or a
       - beta or b
       - milestone or m
       - rc or cr
       - (the empty string) or ga or final
       - sp
     Unknown qualifiers are considered after known qualifiers, with lexical 
order (always case insensitive),
   - a dash usually precedes a qualifier, and is always less important than 
something preceded with a dot.

[1] https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning
[2] 
http://maven.apache.org/ref/3.0.4/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html


>
> On Thu, Oct 10, 2013 at 9:25 AM, Ate Douma <ate@douma.nu> wrote:
>> On 10/10/2013 03:00 PM, James Carman wrote:
>>>
>>> On Thu, Oct 10, 2013 at 8:35 AM, Gary Gregory <garydgregory@gmail.com>
>>> wrote:
>>>>
>>>> I think "milestone" releases works if you have a clear development
>>>> plan and schedule. I've never seen it be the case in Commons. Calling
>>>> "releases" to Maven and dist, Alphas and Betas make more sense for us
>>>> IMO.
>>>>
>>>
>>> I don't care what we call it.  They key is that we set up the
>>> expectation with our users.  If you use this release, do NOT use it in
>>> production code.  It is not "supported", meaning we aren't going to
>>> fix bugs in that alpha version if we have already released its
>>> subsequent full release version (or a subsequent alpha).
>>
>>
>> Indeed and agreed.
>>
>> I also don't care if its called milestone or alpha or whatever.
>> But we already have explicit wording for milestone releases [1], also
>> clearly stating such releases are not supported.
>>
>> So I'm actually only asking *confirmation* to use already established rules.
>>
>> [1] http://commons.apache.org/releases/versioning.html#Milestone_Releases
>>
>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org