Re: [tycho-user] OSGi qualifier vs. maven snapshot

[Laurent PETIT <laurent.petit@xxxxxxxxx>]

2011/10/12 Igor Fedorenko <igor@xxxxxxxxxxxxxx>:
> Although this might work for your project, it really feels like a hack
> or at very least requires long-winded explanation why it works so people
> don't break it by calling their next release 1.0.0.FINAL or 1.0.0.GA.

No more prone to errors than having people don't respect even/odd
scheme or just call it 1.0.0 without much thought, IMHO.

>
> --
> Regards,
> Igor
>
> On 11-10-12 8:35 AM, Laurent PETIT wrote:
>>
>> 2011/10/12 Igor Fedorenko<igor@xxxxxxxxxxxxxx>:
>>>
>>> OSGi does not have a notion of "snapshot" versions, all versions are
>>> treated the same and 1.0.0.qualifier is indeed considered to be newer
>>> than 1.0.0.
>>>
>>> There are two versioning schemes that result is reasonable behaviour
>>> both for OSGi and Maven.
>>>
>>> Use the same four part version (eg., 1.0.0.20111112-0735) for both Maven
>>> and OSGi. This results in slightly odd version jump when going from
>>> snapshots to releases on the maven side, i.e. 1.0.0-SNAPSHOT goes to
>>> 1.0.0.20111112-0735, but everything works otherwise.
>>>
>>> Use even/odd convention to version snapshots and releases, i.e.
>>> 1.0.1-SNAPSHOT/1.0.1.qualifier is released as 1.0.2/1.0.2.
>>>
>>> I think it is also possible to decouple maven and osgi versions of
>>> released artifacts, i.e. use 1.0.0 for maven and 1.0.0.20111112-0735 for
>>> OSGi, but personally I find this confusing and would not recommend. And
>>> I am not sure if Tycho will allow this in the future.
>>
>> My third offer to you, which is what we're using here and seems (to
>> us) most consistent :
>>
>> Use in releases a 4 parts versioning scheme :
>>
>> Let .qualifier/-SNAPSHOT do what they want : 1.0.0.20111112-0735 for
>> example.
>> Release with a letter as the qualifier, not just a 3 parts versioning
>> scheme :
>>
>> 1.0.0.S (or 1.0.0.STABLE)
>>
>> =>  Thus, both for OSGi and Maven, 1.0.0.S will be considered>  any
>> 1.0.0.20111112-073 -like version,
>>   * you make both tools happy
>>   * you do not use even/odd convention which seems (to me) even more a
>> hack than what I'm suggesting
>> =>  Enhancement: it's not everytime that you'll build the "final 1.0.0"
>> (whoops, "final 1.0.0.STABLE") release the first time. Maybe you'll
>> use the same code base, but you've made a mistake in the bundling of
>> things, and you need to restart the build (but not with the same exact
>> version number) =>  for this quite usual problem, I'm just adding one
>> piece : I'm not just adding ".STABLE", but also a "build counter" =>
>> "1.0.0.STABLE001" (Definitely hoping I will not mess up more than 999
>> times the same build :-) )
>>
>> This really works great in practice, and can also help with lifecycles
>> including Beta releases, Release Candidate releases :
>>
>> 1.0.0.20111112-073
>> 1.0.0.20111119-024
>> 1.0.0.BETA001
>> 1.0.0.BETA002
>> 1.0.0.RC001
>> 1.0.0.STABLE001
>>
>> ^^^ look : 2, B, R and C are correctly "alphanumerically" sorted by
>> both maven and OSGi, yeepee !
>>
>>
>>>
>>> --
>>> Regards,
>>> Igor
>>>
>>> On 11-10-12 7:02 AM, Matthias Koester wrote:
>>>>
>>>> Hi,
>>>>
>>>> We are currently using tycho and the tycho-versions-plugin to automate
>>>> the build of our product and use the standard maven convention of using
>>>> "-SNAPSHOT" for development and continous integration. On our git master
>>>> branch we use x.y.z-SNAPSHOT and drop the "-SNAPSHOT" for releasing our
>>>> product. But we now have the impression that this doesn' t work as
>>>> expected, because in OSGi 1.0.0.qualifier seems to be newer than 1.0.0.
>>>> That means that if we reease version 1.0.0 of our product it references
>>>> features and plugins from our latest snapshot release. Or am I missing
>>>> sth.? If I'm right, the question is how others release there products
>>>> with tycho?
>>>>
>>>> Regards,
>>>> Matthias
>>>>
> _______________________________________________
> tycho-user mailing list
> tycho-user@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/tycho-user
>