Hi Yeah the Camel releases has always been as currently. But I do think its better practice to have a .0 so its always 3 digits.
We can maybe start this from Camel 2.18.0 onwards. I assume its "just" a matter when the RC is cut then the version number typed for the Maven command should be 2.18.0 instead of 2.18 in these situations. On Wed, Aug 17, 2016 at 1:01 AM, Raul Kripalani <r...@evosent.com> wrote: > Hi all, > > I've come across an obscure bug using the karaf-maven-plugin to package a > custom Karaf distro containing Camel 2.18-SNAPSHOT. > > Karaf expects feature version numbers to match the same format as OSGi > versions [1]. OSGi versions **require** a micro component. > > Karaf uses the Felix org.apache.felix.utils.version.VersionCleaner [2] > which adds a 0 micro component if it doesn't exist. This magic then causes > problems when other tools try to match version numbers of round releases. > > I particularly find confusing that we use this non-uniform scheme for > versions, not only because it it causes side-effects, but because it feels > somewhat messy. > > My proposal: always include a micro component in our release numbers, > padding with 0 for round releases (2.18 => 2.18.0). That way we would have: > > 2.17.4 > 2.18.0 > 2.18.1 > > Instead of: > > 2.17.4 > 2.18 > 2.18.1 > > Agree? > > [1] https://osgi.org/javadoc/r4v43/core/org/osgi/framework/Version.html > [2] > https://github.com/apache/felix/blob/4a60744d0f88f351551e4cb4673eb60b8fbd21d3/utils/src/main/java/org/apache/felix/utils/version/VersionCleaner.java > > --- > Raúl Kripalani > linkedin.com/in/raulkripalani | evosent.com > <http://evosent.com/?utm_source=email&utm_medium=email&utm_campaign=evosent_raul> > | blog: raul.io > <http://raul.io?utm_source=email&utm_medium=email&utm_campaign=evosent_raul> | > skype: raul.fuse -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
