You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Raul Kripalani <ra...@evosent.com> on 2016/08/16 23:01:55 UTC
Versioning: micro component in round minor releases
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
Re: Versioning: micro component in round minor releases
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Aug 17, 2016 at 4:12 PM, Raul Kripalani <ra...@evosent.com> wrote:
> Hi Claus,
>
> I see your point, but the vast majority of Apache TLP projects are
> publishing SNAPSHOTs per-release, not per version line.
>
> Spark, Kafka, Zookeeper, Aries, Karaf, CXF, Maven, etc. publish per-version
> SNAPSHOTs. I've only found AMQ, Flink and Tomcat doing it like us.
>
> The maintenance/storage problem is an infrastructure concern, not a project
> one. I'm pretty sure that ASF Infrastructure have scaled the system for
> this. If storage were indeed a problem, there is definitely low-hanging
> fruit to deal with first, like our old snapshots from 2.0 to ~2.15, dated
> three years back! https://repository.apache.org/content/groups/
> snapshots/org/apache/camel/camel-atom/
>
> From the perspective of the developer, I would prefer to target a SNAPSHOT
> for a given release rather than a vague one. I've seen customers run Camel
> with SNAPSHOTs in production for months. If you target 2.18-SNAPSHOT, every
> build can result in different dependency versions being taken throughout
> the entire lifetime of a minor release (12–18 months? have a look at the
> 2.15.x release lifespan). However, if you target 2.18.0-SNAPSHOT you know
> that you'll be using code no more recent than 2.18.0 at any given point.
>
That is actually not entirely accurate. The 2.18-SNAPSHOT is only in
use until the 2.18.0 release.
Then any patch releases 2.18.1, 2.18.2 and so on, are using
2.18.1-SNAPSHOT 2.18.2-SNAPSHOT etc.
> It gives the developer more control and scoping.
>
> Cheers.
>
> ---
> 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
>
> On Wed, Aug 17, 2016 at 8:48 AM, Claus Ibsen <cl...@gmail.com> wrote:
>
>> Hi
>>
>> I want the SNAPSHOT to stay as-is on the source code, and only do the
>> .0 on the release builds.
>>
>> Having a plethora of .0-SNAPSHOT .1-SNAPSHOT .2-SNAPSHOT is a pain to
>> work with, and having to prune/remove old versions becomes a
>> maintenance problem.
>>
>> Using -SNAPSHOT then its easy to be assure its using the latest code
>> on that branch, which is the intension of the SNAPSHOT.
>>
>> On Wed, Aug 17, 2016 at 9:35 AM, Raul Kripalani <ra...@evosent.com> wrote:
>> > Hey Claus,
>> >
>> > We can change it now via the versions:set goal. That way we'll start
>> > publishing snapshots under 2.18.0-SNAPSHOT already.
>> >
>> > We should also prune 2.18-SNAPSHOT from the ASF Snapshots repo, to make
>> the
>> > build fail for those who might be using it. That'll make them investigate
>> > and upgrade, rather than silently using an outdated snapshot.
>> >
>> > Cheers.
>> >
>> > On 17 Aug 2016 08:24, "Claus Ibsen" <cl...@gmail.com> wrote:
>> >
>> > 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 <ra...@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/4a60744d0f88f351551e4cb4673eb6
>> > 0b8fbd21d3/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
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Versioning: micro component in round minor releases
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Aug 19, 2016 at 5:25 PM, Raul Kripalani <ra...@evosent.com> wrote:
> On Fri, Aug 19, 2016 at 3:54 PM, Claus Ibsen <cl...@gmail.com> wrote:
>
>> There is already CI jobs for this - they are the ones named notest,
>> which ought to be configured to publish to staging m2 repo after
>> success:
>> https://builds.apache.org/view/A-D/view/Camel/
>>
>
> If I switch the current version to 2.18.0-SNAPSHOT, the snapshots will be
> published under 2.18.0-SNAPSHOT.
>
Yeah sure.
Remember the JIRA and commit message so we can track back to this
change and discussion.
> I meant creating a 2nd job to build and publish the tip of the maintained
> branches under 2.18-SNAPSHOT, 2.17-SNAPSHOT, etc. too – to cover the use
> case you proposed, i.e. "building against the bleeding edge of a release
> line". To me, this is not necessary, but it's a nice to have.
>
Oh we have plenty of CI jobs already. The value of 2.18.0-SNAPSHOT is
leading up to the release. Then the master moves on to 2.19.0-SNAPSHOT
and so on. So lets leave the CI jobs as-is today.
> Cheers.
>
> ---
> 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
Re: Versioning: micro component in round minor releases
Posted by Raul Kripalani <ra...@evosent.com>.
On Fri, Aug 19, 2016 at 3:54 PM, Claus Ibsen <cl...@gmail.com> wrote:
> There is already CI jobs for this - they are the ones named notest,
> which ought to be configured to publish to staging m2 repo after
> success:
> https://builds.apache.org/view/A-D/view/Camel/
>
If I switch the current version to 2.18.0-SNAPSHOT, the snapshots will be
published under 2.18.0-SNAPSHOT.
I meant creating a 2nd job to build and publish the tip of the maintained
branches under 2.18-SNAPSHOT, 2.17-SNAPSHOT, etc. too – to cover the use
case you proposed, i.e. "building against the bleeding edge of a release
line". To me, this is not necessary, but it's a nice to have.
Cheers.
---
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
Re: Versioning: micro component in round minor releases
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Aug 19, 2016 at 4:27 PM, Raul Kripalani <ra...@evosent.com> wrote:
> Not particularly with Camel, Claus, but I've seen this in other contexts.
>
> There are a variety of reasons why one might run a **controlled** snapshot
> in production: maybe it's a proof of concept with limited exposure, maybe
> one has a full Continuous Delivery pipeline with Canary techniques where
> you only allow like 1% of the traffic to hit your snapshot (rest goes to
> release) in order to pre-emptively test upstream changes and detect
> breakages... It's not the most common scenario though, and discouraged for
> most customers
> if they don't know what they're doing, of course.
>
> Nevertheless, we shouldn't be hindering use cases here at the community, we
> should focus on making Camel
> play nicely
> whether it's a snapshot or not.
>
> With the current versioning scheme, we have problems with .0 releases, and
> also there is ambiguity because 2.18-SNAPSHOT actually refers to
> 2.18.0-SNAPSHOT and not to "the latest in the 2.18.x line".
>
> What I propose is:
>
>
> #
> 1 To r
> ename the current version to 2.18.0-SNAPSHOT
>
> .
> Make all versions have major.minor.micro tokens, even if they are 0.
>
Yeah sure the .0 is a good idea.
> #2 To s
> et up a new CI job in Jenkins to build and publish nightlies of the tips of
> the actively maintained release lines (2.18.x, 2.17.x, 2.16.x) to the
> snapshots repo under 2.18-SNAPSHOT & co.
>
There is already CI jobs for this - they are the ones named notest,
which ought to be configured to publish to staging m2 repo after
success:
https://builds.apache.org/view/A-D/view/Camel/
We may want to log a JIRA about this, and then add a link in the
comment to point to this talk on nabble so people can find it in the
future. And in the commit log remember to add the JIRA number.
And add a note on the release notes about the 2.18.0 version number.
http://camel.apache.org/camel-2180-release.html
> WYDT?
>
> Cheers.
>
> On 19 Aug 2016 14:32, "Claus Ibsen" <cl...@gmail.com> wrote:
>
>> On Wed, Aug 17, 2016 at 4:12 PM, Raul Kripalani <ra...@evosent.com> wrote:
>> > Hi Claus,
>> >
>> > I see your point, but the vast majority of Apache TLP projects are
>> > publishing SNAPSHOTs per-release, not per version line.
>> >
>> > Spark, Kafka, Zookeeper, Aries, Karaf, CXF, Maven, etc. publish
>> per-version
>> > SNAPSHOTs. I've only found AMQ, Flink and Tomcat doing it like us.
>> >
>> > The maintenance/storage problem is an infrastructure concern, not a
>> project
>> > one. I'm pretty sure that ASF Infrastructure have scaled the system for
>> > this. If storage were indeed a problem, there is definitely low-hanging
>> > fruit to deal with first, like our old snapshots from 2.0 to ~2.15, dated
>> > three years back! https://repository.apache.org/content/groups/
>> > snapshots/org/apache/camel/camel-atom/
>> >
>> > From the perspective of the developer, I would prefer to target a
>> SNAPSHOT
>> > for a given release rather than a vague one. I've seen customers run
>> Camel
>> > with SNAPSHOTs in production for months. If you target 2.18-SNAPSHOT,
>> every
>>
>> Have you talked with those customers why they are running with
>> SNAPSHOT in production?
>> How did that get in there in the first place, and why is Karaf so
>> "lenient"? Maybe something to take
>> to the Karaf team to make it "stand out" that you run SNAPSHOT bundles.
>>
>> I can see out of the box Apache Karaf has ASF snapshot repo included
>> out of the box (very bad imho)
>>
>>
>> org.ops4j.pax.url.mvn.repositories= \
>> http://repo1.maven.org/maven2@id=central, \
>> http://repository.springsource.com/maven/bundles/release@id=
>> spring.ebr.release,
>> \
>> http://repository.springsource.com/maven/bundles/external@
>> id=spring.ebr.external,
>> \
>> http://zodiac.springsource.com/maven/bundles/release@id=gemini, \
>> http://repository.apache.org/content/groups/snapshots-group@
>> id=apache@snapshots@noreleases,
>> \
>> https://oss.sonatype.org/content/repositories/snapshots@id=
>> sonatype.snapshots.deploy@snapshots@noreleases,
>> \
>> https://oss.sonatype.org/content/repositories/ops4j-snapshot
>> s@id=ops4j.sonatype.snapshots.deploy@snapshots@noreleases,
>> \
>> http://repository.springsource.com/maven/bundles/external@
>> id=spring-ebr-repository@snapshots@noreleases
>>
>>
>>
>>
>>
>> > build can result in different dependency versions being taken throughout
>> > the entire lifetime of a minor release (12–18 months? have a look at the
>> > 2.15.x release lifespan). However, if you target 2.18.0-SNAPSHOT you know
>> > that you'll be using code no more recent than 2.18.0 at any given point.
>> >
>> > It gives the developer more control and scoping.
>> >
>> > Cheers.
>> >
>> > ---
>> > 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_campai
>> gn=evosent_raul> |
>> > skype: raul.fuse
>> >
>> > On Wed, Aug 17, 2016 at 8:48 AM, Claus Ibsen <cl...@gmail.com>
>> wrote:
>> >
>> >> Hi
>> >>
>> >> I want the SNAPSHOT to stay as-is on the source code, and only do the
>> >> .0 on the release builds.
>> >>
>> >> Having a plethora of .0-SNAPSHOT .1-SNAPSHOT .2-SNAPSHOT is a pain to
>> >> work with, and having to prune/remove old versions becomes a
>> >> maintenance problem.
>> >>
>> >> Using -SNAPSHOT then its easy to be assure its using the latest code
>> >> on that branch, which is the intension of the SNAPSHOT.
>> >>
>> >> On Wed, Aug 17, 2016 at 9:35 AM, Raul Kripalani <ra...@evosent.com>
>> wrote:
>> >> > Hey Claus,
>> >> >
>> >> > We can change it now via the versions:set goal. That way we'll start
>> >> > publishing snapshots under 2.18.0-SNAPSHOT already.
>> >> >
>> >> > We should also prune 2.18-SNAPSHOT from the ASF Snapshots repo, to
>> make
>> >> the
>> >> > build fail for those who might be using it. That'll make them
>> investigate
>> >> > and upgrade, rather than silently using an outdated snapshot.
>> >> >
>> >> > Cheers.
>> >> >
>> >> > On 17 Aug 2016 08:24, "Claus Ibsen" <cl...@gmail.com> wrote:
>> >> >
>> >> > 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 <ra...@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/Versi
>> on.html
>> >> >> [2]
>> >> >> https://github.com/apache/felix/blob/4a60744d0f88f351551e4cb4673eb6
>> >> > 0b8fbd21d3/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
>> >>
>> >>
>> >>
>> >> --
>> >> Claus Ibsen
>> >> -----------------
>> >> http://davsclaus.com @davsclaus
>> >> Camel in Action 2: https://www.manning.com/ibsen2
>> >>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Versioning: micro component in round minor releases
Posted by Raul Kripalani <ra...@evosent.com>.
Not particularly with Camel, Claus, but I've seen this in other contexts.
There are a variety of reasons why one might run a **controlled** snapshot
in production: maybe it's a proof of concept with limited exposure, maybe
one has a full Continuous Delivery pipeline with Canary techniques where
you only allow like 1% of the traffic to hit your snapshot (rest goes to
release) in order to pre-emptively test upstream changes and detect
breakages... It's not the most common scenario though, and discouraged for
most customers
if they don't know what they're doing, of course.
Nevertheless, we shouldn't be hindering use cases here at the community, we
should focus on making Camel
play nicely
whether it's a snapshot or not.
With the current versioning scheme, we have problems with .0 releases, and
also there is ambiguity because 2.18-SNAPSHOT actually refers to
2.18.0-SNAPSHOT and not to "the latest in the 2.18.x line".
What I propose is:
#
1 To r
ename the current version to 2.18.0-SNAPSHOT
.
Make all versions have major.minor.micro tokens, even if they are 0.
#2 To s
et up a new CI job in Jenkins to build and publish nightlies of the tips of
the actively maintained release lines (2.18.x, 2.17.x, 2.16.x) to the
snapshots repo under 2.18-SNAPSHOT & co.
WYDT?
Cheers.
On 19 Aug 2016 14:32, "Claus Ibsen" <cl...@gmail.com> wrote:
> On Wed, Aug 17, 2016 at 4:12 PM, Raul Kripalani <ra...@evosent.com> wrote:
> > Hi Claus,
> >
> > I see your point, but the vast majority of Apache TLP projects are
> > publishing SNAPSHOTs per-release, not per version line.
> >
> > Spark, Kafka, Zookeeper, Aries, Karaf, CXF, Maven, etc. publish
> per-version
> > SNAPSHOTs. I've only found AMQ, Flink and Tomcat doing it like us.
> >
> > The maintenance/storage problem is an infrastructure concern, not a
> project
> > one. I'm pretty sure that ASF Infrastructure have scaled the system for
> > this. If storage were indeed a problem, there is definitely low-hanging
> > fruit to deal with first, like our old snapshots from 2.0 to ~2.15, dated
> > three years back! https://repository.apache.org/content/groups/
> > snapshots/org/apache/camel/camel-atom/
> >
> > From the perspective of the developer, I would prefer to target a
> SNAPSHOT
> > for a given release rather than a vague one. I've seen customers run
> Camel
> > with SNAPSHOTs in production for months. If you target 2.18-SNAPSHOT,
> every
>
> Have you talked with those customers why they are running with
> SNAPSHOT in production?
> How did that get in there in the first place, and why is Karaf so
> "lenient"? Maybe something to take
> to the Karaf team to make it "stand out" that you run SNAPSHOT bundles.
>
> I can see out of the box Apache Karaf has ASF snapshot repo included
> out of the box (very bad imho)
>
>
> org.ops4j.pax.url.mvn.repositories= \
> http://repo1.maven.org/maven2@id=central, \
> http://repository.springsource.com/maven/bundles/release@id=
> spring.ebr.release,
> \
> http://repository.springsource.com/maven/bundles/external@
> id=spring.ebr.external,
> \
> http://zodiac.springsource.com/maven/bundles/release@id=gemini, \
> http://repository.apache.org/content/groups/snapshots-group@
> id=apache@snapshots@noreleases,
> \
> https://oss.sonatype.org/content/repositories/snapshots@id=
> sonatype.snapshots.deploy@snapshots@noreleases,
> \
> https://oss.sonatype.org/content/repositories/ops4j-snapshot
> s@id=ops4j.sonatype.snapshots.deploy@snapshots@noreleases,
> \
> http://repository.springsource.com/maven/bundles/external@
> id=spring-ebr-repository@snapshots@noreleases
>
>
>
>
>
> > build can result in different dependency versions being taken throughout
> > the entire lifetime of a minor release (12–18 months? have a look at the
> > 2.15.x release lifespan). However, if you target 2.18.0-SNAPSHOT you know
> > that you'll be using code no more recent than 2.18.0 at any given point.
> >
> > It gives the developer more control and scoping.
> >
> > Cheers.
> >
> > ---
> > 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_campai
> gn=evosent_raul> |
> > skype: raul.fuse
> >
> > On Wed, Aug 17, 2016 at 8:48 AM, Claus Ibsen <cl...@gmail.com>
> wrote:
> >
> >> Hi
> >>
> >> I want the SNAPSHOT to stay as-is on the source code, and only do the
> >> .0 on the release builds.
> >>
> >> Having a plethora of .0-SNAPSHOT .1-SNAPSHOT .2-SNAPSHOT is a pain to
> >> work with, and having to prune/remove old versions becomes a
> >> maintenance problem.
> >>
> >> Using -SNAPSHOT then its easy to be assure its using the latest code
> >> on that branch, which is the intension of the SNAPSHOT.
> >>
> >> On Wed, Aug 17, 2016 at 9:35 AM, Raul Kripalani <ra...@evosent.com>
> wrote:
> >> > Hey Claus,
> >> >
> >> > We can change it now via the versions:set goal. That way we'll start
> >> > publishing snapshots under 2.18.0-SNAPSHOT already.
> >> >
> >> > We should also prune 2.18-SNAPSHOT from the ASF Snapshots repo, to
> make
> >> the
> >> > build fail for those who might be using it. That'll make them
> investigate
> >> > and upgrade, rather than silently using an outdated snapshot.
> >> >
> >> > Cheers.
> >> >
> >> > On 17 Aug 2016 08:24, "Claus Ibsen" <cl...@gmail.com> wrote:
> >> >
> >> > 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 <ra...@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/Versi
> on.html
> >> >> [2]
> >> >> https://github.com/apache/felix/blob/4a60744d0f88f351551e4cb4673eb6
> >> > 0b8fbd21d3/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
> >>
> >>
> >>
> >> --
> >> Claus Ibsen
> >> -----------------
> >> http://davsclaus.com @davsclaus
> >> Camel in Action 2: https://www.manning.com/ibsen2
> >>
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
Re: Versioning: micro component in round minor releases
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Aug 17, 2016 at 4:12 PM, Raul Kripalani <ra...@evosent.com> wrote:
> Hi Claus,
>
> I see your point, but the vast majority of Apache TLP projects are
> publishing SNAPSHOTs per-release, not per version line.
>
> Spark, Kafka, Zookeeper, Aries, Karaf, CXF, Maven, etc. publish per-version
> SNAPSHOTs. I've only found AMQ, Flink and Tomcat doing it like us.
>
> The maintenance/storage problem is an infrastructure concern, not a project
> one. I'm pretty sure that ASF Infrastructure have scaled the system for
> this. If storage were indeed a problem, there is definitely low-hanging
> fruit to deal with first, like our old snapshots from 2.0 to ~2.15, dated
> three years back! https://repository.apache.org/content/groups/
> snapshots/org/apache/camel/camel-atom/
>
> From the perspective of the developer, I would prefer to target a SNAPSHOT
> for a given release rather than a vague one. I've seen customers run Camel
> with SNAPSHOTs in production for months. If you target 2.18-SNAPSHOT, every
Have you talked with those customers why they are running with
SNAPSHOT in production?
How did that get in there in the first place, and why is Karaf so
"lenient"? Maybe something to take
to the Karaf team to make it "stand out" that you run SNAPSHOT bundles.
I can see out of the box Apache Karaf has ASF snapshot repo included
out of the box (very bad imho)
org.ops4j.pax.url.mvn.repositories= \
http://repo1.maven.org/maven2@id=central, \
http://repository.springsource.com/maven/bundles/release@id=spring.ebr.release,
\
http://repository.springsource.com/maven/bundles/external@id=spring.ebr.external,
\
http://zodiac.springsource.com/maven/bundles/release@id=gemini, \
http://repository.apache.org/content/groups/snapshots-group@id=apache@snapshots@noreleases,
\
https://oss.sonatype.org/content/repositories/snapshots@id=sonatype.snapshots.deploy@snapshots@noreleases,
\
https://oss.sonatype.org/content/repositories/ops4j-snapshots@id=ops4j.sonatype.snapshots.deploy@snapshots@noreleases,
\
http://repository.springsource.com/maven/bundles/external@id=spring-ebr-repository@snapshots@noreleases
> build can result in different dependency versions being taken throughout
> the entire lifetime of a minor release (12–18 months? have a look at the
> 2.15.x release lifespan). However, if you target 2.18.0-SNAPSHOT you know
> that you'll be using code no more recent than 2.18.0 at any given point.
>
> It gives the developer more control and scoping.
>
> Cheers.
>
> ---
> 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
>
> On Wed, Aug 17, 2016 at 8:48 AM, Claus Ibsen <cl...@gmail.com> wrote:
>
>> Hi
>>
>> I want the SNAPSHOT to stay as-is on the source code, and only do the
>> .0 on the release builds.
>>
>> Having a plethora of .0-SNAPSHOT .1-SNAPSHOT .2-SNAPSHOT is a pain to
>> work with, and having to prune/remove old versions becomes a
>> maintenance problem.
>>
>> Using -SNAPSHOT then its easy to be assure its using the latest code
>> on that branch, which is the intension of the SNAPSHOT.
>>
>> On Wed, Aug 17, 2016 at 9:35 AM, Raul Kripalani <ra...@evosent.com> wrote:
>> > Hey Claus,
>> >
>> > We can change it now via the versions:set goal. That way we'll start
>> > publishing snapshots under 2.18.0-SNAPSHOT already.
>> >
>> > We should also prune 2.18-SNAPSHOT from the ASF Snapshots repo, to make
>> the
>> > build fail for those who might be using it. That'll make them investigate
>> > and upgrade, rather than silently using an outdated snapshot.
>> >
>> > Cheers.
>> >
>> > On 17 Aug 2016 08:24, "Claus Ibsen" <cl...@gmail.com> wrote:
>> >
>> > 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 <ra...@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/4a60744d0f88f351551e4cb4673eb6
>> > 0b8fbd21d3/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
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Versioning: micro component in round minor releases
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Aug 17, 2016 at 4:22 PM, Raul Kripalani <ra...@evosent.com> wrote:
> Also Claus, I found a mixture of per-release-line SNAPSHOTS and per-release
> SNAPSHOTs in our repo:
> https://repository.apache.org/content/groups/snapshots/org/apache/camel/camel-core.
> Not sure if this is intentional or not.
>
> This is what we have for 2.17.x. I think your expectations are not met
> anyway?
>
>
> 2.17-SNAPSHOT/ Wed Aug 17 01:28:59 UTC 2016
> 2.17.2-SNAPSHOT/ Fri Jul 01 17:39:01 UTC 2016
> 2.17.3-SNAPSHOT/ Mon Aug 08 05:55:48 UTC 2016
> 2.17.4-SNAPSHOT/ Wed Aug 17 01:25:06 UTC 2016
>
>
> 2.17-SNAPSHOT is actually equivalent to 2.17.0-SNAPSHOT, not "the latest
> snapshot of 2.17.x", which is what I understood you wanted?
>
Not entirely. I want -SNAPSHOT to be the next version on master before
there is a release.
This makes it super easy to try the latest code. I have worked with
other projects where they change versions numbers more frequently and
its a pain to keep track what is the latest if you have to chase down
if its .4 .7 .99 or whatever the number is today.
Those 2.17.1-SNAPSHOT etc. are after a release when there is a branch
2.17.x branch, and we cherry-pick bug fixes to these branches. Then
the CI server builds SNAPSHOT.
But we could still have -SNAPSHOT as the next version on master, if
its named .0-SNAPSHOT. eg with the zero number.
Then you have what you ask about also.
> Also, doing the .0 on release builds only doesn't help users who want to
> get the feature repository working with 2.17(.0) while it's still a
> SNAPSHOT, for example.
>
> Cheers.
>
> ---
> 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
>
> On Wed, Aug 17, 2016 at 3:12 PM, Raul Kripalani <ra...@evosent.com> wrote:
>
>> Hi Claus,
>>
>> I see your point, but the vast majority of Apache TLP projects are
>> publishing SNAPSHOTs per-release, not per version line.
>>
>> Spark, Kafka, Zookeeper, Aries, Karaf, CXF, Maven, etc. publish
>> per-version SNAPSHOTs. I've only found AMQ, Flink and Tomcat doing it like
>> us.
>>
>> The maintenance/storage problem is an infrastructure concern, not a
>> project one. I'm pretty sure that ASF Infrastructure have scaled the system
>> for this. If storage were indeed a problem, there is definitely low-hanging
>> fruit to deal with first, like our old snapshots from 2.0 to ~2.15, dated
>> three years back! https://repository.apache.org/content/groups/snapshots
>> /org/apache/camel/camel-atom/
>>
>> From the perspective of the developer, I would prefer to target a SNAPSHOT
>> for a given release rather than a vague one. I've seen customers run Camel
>> with SNAPSHOTs in production for months. If you target 2.18-SNAPSHOT, every
>> build can result in different dependency versions being taken throughout
>> the entire lifetime of a minor release (12–18 months? have a look at the
>> 2.15.x release lifespan). However, if you target 2.18.0-SNAPSHOT you know
>> that you'll be using code no more recent than 2.18.0 at any given point.
>>
>> It gives the developer more control and scoping.
>>
>> Cheers.
>>
>> ---
>> 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
>>
>> On Wed, Aug 17, 2016 at 8:48 AM, Claus Ibsen <cl...@gmail.com>
>> wrote:
>>
>>> Hi
>>>
>>> I want the SNAPSHOT to stay as-is on the source code, and only do the
>>> .0 on the release builds.
>>>
>>> Having a plethora of .0-SNAPSHOT .1-SNAPSHOT .2-SNAPSHOT is a pain to
>>> work with, and having to prune/remove old versions becomes a
>>> maintenance problem.
>>>
>>> Using -SNAPSHOT then its easy to be assure its using the latest code
>>> on that branch, which is the intension of the SNAPSHOT.
>>>
>>> On Wed, Aug 17, 2016 at 9:35 AM, Raul Kripalani <ra...@evosent.com> wrote:
>>> > Hey Claus,
>>> >
>>> > We can change it now via the versions:set goal. That way we'll start
>>> > publishing snapshots under 2.18.0-SNAPSHOT already.
>>> >
>>> > We should also prune 2.18-SNAPSHOT from the ASF Snapshots repo, to make
>>> the
>>> > build fail for those who might be using it. That'll make them
>>> investigate
>>> > and upgrade, rather than silently using an outdated snapshot.
>>> >
>>> > Cheers.
>>> >
>>> > On 17 Aug 2016 08:24, "Claus Ibsen" <cl...@gmail.com> wrote:
>>> >
>>> > 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 <ra...@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/Versi
>>> on.html
>>> >> [2]
>>> >> https://github.com/apache/felix/blob/4a60744d0f88f351551e4cb4673eb6
>>> > 0b8fbd21d3/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
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>
>>
>>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Versioning: micro component in round minor releases
Posted by Raul Kripalani <ra...@evosent.com>.
Hi Claus,
Any further thoughts?
This is becoming an ongoing problem in my projects and I'd appreciate your
views before making any changes.
Cheers!
On 17 Aug 2016 15:22, "Raul Kripalani" <ra...@evosent.com> wrote:
> Also Claus, I found a mixture of per-release-line SNAPSHOTS and
> per-release SNAPSHOTs in our repo: https://repository.
> apache.org/content/groups/snapshots/org/apache/camel/camel-core. Not sure
> if this is intentional or not.
>
> This is what we have for 2.17.x. I think your expectations are not met
> anyway?
>
>
> 2.17-SNAPSHOT/ Wed Aug 17 01:28:59 UTC 2016
> 2.17.2-SNAPSHOT/ Fri Jul 01 17:39:01 UTC 2016
> 2.17.3-SNAPSHOT/ Mon Aug 08 05:55:48 UTC 2016
> 2.17.4-SNAPSHOT/ Wed Aug 17 01:25:06 UTC 2016
>
>
> 2.17-SNAPSHOT is actually equivalent to 2.17.0-SNAPSHOT, not "the latest
> snapshot of 2.17.x", which is what I understood you wanted?
>
> Also, doing the .0 on release builds only doesn't help users who want to
> get the feature repository working with 2.17(.0) while it's still a
> SNAPSHOT, for example.
>
> Cheers.
>
> ---
> 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
>
> On Wed, Aug 17, 2016 at 3:12 PM, Raul Kripalani <ra...@evosent.com> wrote:
>
>> Hi Claus,
>>
>> I see your point, but the vast majority of Apache TLP projects are
>> publishing SNAPSHOTs per-release, not per version line.
>>
>> Spark, Kafka, Zookeeper, Aries, Karaf, CXF, Maven, etc. publish
>> per-version SNAPSHOTs. I've only found AMQ, Flink and Tomcat doing it like
>> us.
>>
>> The maintenance/storage problem is an infrastructure concern, not a
>> project one. I'm pretty sure that ASF Infrastructure have scaled the system
>> for this. If storage were indeed a problem, there is definitely low-hanging
>> fruit to deal with first, like our old snapshots from 2.0 to ~2.15, dated
>> three years back! https://repository.apache.org/content/groups/snapshots
>> /org/apache/camel/camel-atom/
>>
>> From the perspective of the developer, I would prefer to target a
>> SNAPSHOT for a given release rather than a vague one. I've seen customers
>> run Camel with SNAPSHOTs in production for months. If you target
>> 2.18-SNAPSHOT, every build can result in different dependency versions
>> being taken throughout the entire lifetime of a minor release (12–18
>> months? have a look at the 2.15.x release lifespan). However, if you target
>> 2.18.0-SNAPSHOT you know that you'll be using code no more recent than
>> 2.18.0 at any given point.
>>
>> It gives the developer more control and scoping.
>>
>> Cheers.
>>
>> ---
>> 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
>>
>> On Wed, Aug 17, 2016 at 8:48 AM, Claus Ibsen <cl...@gmail.com>
>> wrote:
>>
>>> Hi
>>>
>>> I want the SNAPSHOT to stay as-is on the source code, and only do the
>>> .0 on the release builds.
>>>
>>> Having a plethora of .0-SNAPSHOT .1-SNAPSHOT .2-SNAPSHOT is a pain to
>>> work with, and having to prune/remove old versions becomes a
>>> maintenance problem.
>>>
>>> Using -SNAPSHOT then its easy to be assure its using the latest code
>>> on that branch, which is the intension of the SNAPSHOT.
>>>
>>> On Wed, Aug 17, 2016 at 9:35 AM, Raul Kripalani <ra...@evosent.com>
>>> wrote:
>>> > Hey Claus,
>>> >
>>> > We can change it now via the versions:set goal. That way we'll start
>>> > publishing snapshots under 2.18.0-SNAPSHOT already.
>>> >
>>> > We should also prune 2.18-SNAPSHOT from the ASF Snapshots repo, to
>>> make the
>>> > build fail for those who might be using it. That'll make them
>>> investigate
>>> > and upgrade, rather than silently using an outdated snapshot.
>>> >
>>> > Cheers.
>>> >
>>> > On 17 Aug 2016 08:24, "Claus Ibsen" <cl...@gmail.com> wrote:
>>> >
>>> > 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 <ra...@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/Versi
>>> on.html
>>> >> [2]
>>> >> https://github.com/apache/felix/blob/4a60744d0f88f351551e4cb4673eb6
>>> > 0b8fbd21d3/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
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>
>>
>>
>
Re: Versioning: micro component in round minor releases
Posted by Raul Kripalani <ra...@evosent.com>.
Also Claus, I found a mixture of per-release-line SNAPSHOTS and per-release
SNAPSHOTs in our repo:
https://repository.apache.org/content/groups/snapshots/org/apache/camel/camel-core.
Not sure if this is intentional or not.
This is what we have for 2.17.x. I think your expectations are not met
anyway?
2.17-SNAPSHOT/ Wed Aug 17 01:28:59 UTC 2016
2.17.2-SNAPSHOT/ Fri Jul 01 17:39:01 UTC 2016
2.17.3-SNAPSHOT/ Mon Aug 08 05:55:48 UTC 2016
2.17.4-SNAPSHOT/ Wed Aug 17 01:25:06 UTC 2016
2.17-SNAPSHOT is actually equivalent to 2.17.0-SNAPSHOT, not "the latest
snapshot of 2.17.x", which is what I understood you wanted?
Also, doing the .0 on release builds only doesn't help users who want to
get the feature repository working with 2.17(.0) while it's still a
SNAPSHOT, for example.
Cheers.
---
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
On Wed, Aug 17, 2016 at 3:12 PM, Raul Kripalani <ra...@evosent.com> wrote:
> Hi Claus,
>
> I see your point, but the vast majority of Apache TLP projects are
> publishing SNAPSHOTs per-release, not per version line.
>
> Spark, Kafka, Zookeeper, Aries, Karaf, CXF, Maven, etc. publish
> per-version SNAPSHOTs. I've only found AMQ, Flink and Tomcat doing it like
> us.
>
> The maintenance/storage problem is an infrastructure concern, not a
> project one. I'm pretty sure that ASF Infrastructure have scaled the system
> for this. If storage were indeed a problem, there is definitely low-hanging
> fruit to deal with first, like our old snapshots from 2.0 to ~2.15, dated
> three years back! https://repository.apache.org/content/groups/snapshots
> /org/apache/camel/camel-atom/
>
> From the perspective of the developer, I would prefer to target a SNAPSHOT
> for a given release rather than a vague one. I've seen customers run Camel
> with SNAPSHOTs in production for months. If you target 2.18-SNAPSHOT, every
> build can result in different dependency versions being taken throughout
> the entire lifetime of a minor release (12–18 months? have a look at the
> 2.15.x release lifespan). However, if you target 2.18.0-SNAPSHOT you know
> that you'll be using code no more recent than 2.18.0 at any given point.
>
> It gives the developer more control and scoping.
>
> Cheers.
>
> ---
> 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
>
> On Wed, Aug 17, 2016 at 8:48 AM, Claus Ibsen <cl...@gmail.com>
> wrote:
>
>> Hi
>>
>> I want the SNAPSHOT to stay as-is on the source code, and only do the
>> .0 on the release builds.
>>
>> Having a plethora of .0-SNAPSHOT .1-SNAPSHOT .2-SNAPSHOT is a pain to
>> work with, and having to prune/remove old versions becomes a
>> maintenance problem.
>>
>> Using -SNAPSHOT then its easy to be assure its using the latest code
>> on that branch, which is the intension of the SNAPSHOT.
>>
>> On Wed, Aug 17, 2016 at 9:35 AM, Raul Kripalani <ra...@evosent.com> wrote:
>> > Hey Claus,
>> >
>> > We can change it now via the versions:set goal. That way we'll start
>> > publishing snapshots under 2.18.0-SNAPSHOT already.
>> >
>> > We should also prune 2.18-SNAPSHOT from the ASF Snapshots repo, to make
>> the
>> > build fail for those who might be using it. That'll make them
>> investigate
>> > and upgrade, rather than silently using an outdated snapshot.
>> >
>> > Cheers.
>> >
>> > On 17 Aug 2016 08:24, "Claus Ibsen" <cl...@gmail.com> wrote:
>> >
>> > 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 <ra...@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/Versi
>> on.html
>> >> [2]
>> >> https://github.com/apache/felix/blob/4a60744d0f88f351551e4cb4673eb6
>> > 0b8fbd21d3/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
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>>
>
>
Re: Versioning: micro component in round minor releases
Posted by Raul Kripalani <ra...@evosent.com>.
Hi Claus,
I see your point, but the vast majority of Apache TLP projects are
publishing SNAPSHOTs per-release, not per version line.
Spark, Kafka, Zookeeper, Aries, Karaf, CXF, Maven, etc. publish per-version
SNAPSHOTs. I've only found AMQ, Flink and Tomcat doing it like us.
The maintenance/storage problem is an infrastructure concern, not a project
one. I'm pretty sure that ASF Infrastructure have scaled the system for
this. If storage were indeed a problem, there is definitely low-hanging
fruit to deal with first, like our old snapshots from 2.0 to ~2.15, dated
three years back! https://repository.apache.org/content/groups/
snapshots/org/apache/camel/camel-atom/
From the perspective of the developer, I would prefer to target a SNAPSHOT
for a given release rather than a vague one. I've seen customers run Camel
with SNAPSHOTs in production for months. If you target 2.18-SNAPSHOT, every
build can result in different dependency versions being taken throughout
the entire lifetime of a minor release (12–18 months? have a look at the
2.15.x release lifespan). However, if you target 2.18.0-SNAPSHOT you know
that you'll be using code no more recent than 2.18.0 at any given point.
It gives the developer more control and scoping.
Cheers.
---
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
On Wed, Aug 17, 2016 at 8:48 AM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> I want the SNAPSHOT to stay as-is on the source code, and only do the
> .0 on the release builds.
>
> Having a plethora of .0-SNAPSHOT .1-SNAPSHOT .2-SNAPSHOT is a pain to
> work with, and having to prune/remove old versions becomes a
> maintenance problem.
>
> Using -SNAPSHOT then its easy to be assure its using the latest code
> on that branch, which is the intension of the SNAPSHOT.
>
> On Wed, Aug 17, 2016 at 9:35 AM, Raul Kripalani <ra...@evosent.com> wrote:
> > Hey Claus,
> >
> > We can change it now via the versions:set goal. That way we'll start
> > publishing snapshots under 2.18.0-SNAPSHOT already.
> >
> > We should also prune 2.18-SNAPSHOT from the ASF Snapshots repo, to make
> the
> > build fail for those who might be using it. That'll make them investigate
> > and upgrade, rather than silently using an outdated snapshot.
> >
> > Cheers.
> >
> > On 17 Aug 2016 08:24, "Claus Ibsen" <cl...@gmail.com> wrote:
> >
> > 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 <ra...@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/4a60744d0f88f351551e4cb4673eb6
> > 0b8fbd21d3/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
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
Re: Versioning: micro component in round minor releases
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
I want the SNAPSHOT to stay as-is on the source code, and only do the
.0 on the release builds.
Having a plethora of .0-SNAPSHOT .1-SNAPSHOT .2-SNAPSHOT is a pain to
work with, and having to prune/remove old versions becomes a
maintenance problem.
Using -SNAPSHOT then its easy to be assure its using the latest code
on that branch, which is the intension of the SNAPSHOT.
On Wed, Aug 17, 2016 at 9:35 AM, Raul Kripalani <ra...@evosent.com> wrote:
> Hey Claus,
>
> We can change it now via the versions:set goal. That way we'll start
> publishing snapshots under 2.18.0-SNAPSHOT already.
>
> We should also prune 2.18-SNAPSHOT from the ASF Snapshots repo, to make the
> build fail for those who might be using it. That'll make them investigate
> and upgrade, rather than silently using an outdated snapshot.
>
> Cheers.
>
> On 17 Aug 2016 08:24, "Claus Ibsen" <cl...@gmail.com> wrote:
>
> 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 <ra...@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/4a60744d0f88f351551e4cb4673eb6
> 0b8fbd21d3/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
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Versioning: micro component in round minor releases
Posted by Raul Kripalani <ra...@evosent.com>.
Hey Claus,
We can change it now via the versions:set goal. That way we'll start
publishing snapshots under 2.18.0-SNAPSHOT already.
We should also prune 2.18-SNAPSHOT from the ASF Snapshots repo, to make the
build fail for those who might be using it. That'll make them investigate
and upgrade, rather than silently using an outdated snapshot.
Cheers.
On 17 Aug 2016 08:24, "Claus Ibsen" <cl...@gmail.com> wrote:
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 <ra...@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/4a60744d0f88f351551e4cb4673eb6
0b8fbd21d3/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
Re: Versioning: micro component in round minor releases
Posted by Claus Ibsen <cl...@gmail.com>.
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 <ra...@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