That's exactly how we manage the version #s for branches. We use the
convention that the leading number comes from the source of the branch
(usually the trunk), then we add a meaningful identifier for the branch, and
finally a branch version that can be incremented by the release process -

6.0.0-mybranch-2.1-SNAPSHOT

See - 
http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-p
om-syntax.html#pom-relationships-sect-version-build-numbers

Rick




On 4/16/10 9:23 AM, "Stephen Connolly" <[email protected]>
wrote:

> who said version numbers have to be numbers!
> 
> 6.0.0-mybranch-SNAPSHOT
> 6.0.0-yourbranch-SNAPSHOT,
> 
> etc
> 
> On 16 April 2010 13:09, Nicola Musatti <[email protected]> wrote:
> 
>> Stephen Connolly wrote:
>> 
>>> different branches should have different version numbers
>>> 
>> This would be reasonable if I only issued maintenance releases from my
>> branches. In my case however branches evolve independently and I'd rather
>> not assign them arbitrary version numbers.
>> 
>> Cheers,
>> Nicola Musatti
>> 
>>  On 16 April 2010 11:12, Nicola Musatti <[email protected]<mailto:
>>> [email protected]>> wrote:
>>> 
>>>    Hallo,
>>>    I have different branches of the same project that are being
>>>    developed in parallel, to cater for customer customizations. Is
>>>    there a standard way to identify the resulting artifacts? At first
>>>    I thought of giving each a different classifier, but I'm under the
>>>    impression that this is not what classifiers are meant for, as
>>>    I've only seen them used to identify build variants obtained from
>>>    the same set of sources.
>>> 
>>>    Thanks,
>>>    Nicola Musatti
>>> 
>>>    ---------------------------------------------------------------------
>>>    To unsubscribe, e-mail: [email protected]
>>>    <mailto:[email protected]>
>>> 
>>>    For additional commands, e-mail: [email protected]
>>>    <mailto:[email protected]>
>>> 
>>> 
>>> 
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to