Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-user] OSGi qualifier vs. maven snapshot

Hi,

We already discussed internally the solution Igor suggested. But we thought that there may be a better solution. Thanks to Igor we are now sure that we are using the right approach ;-)

Regards,
Matthias

On Wed, Oct 12, 2011 at 3:23 PM, Igor Fedorenko <igor@xxxxxxxxxxxxxx> wrote:
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.

--
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


Back to the top