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" <claus.ib...@gmail.com> wrote:
> On Wed, Aug 17, 2016 at 4:12 PM, Raul Kripalani <r...@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 <claus.ib...@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 <r...@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" <claus.ib...@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 <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/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
>
