camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: Versioning: micro component in round minor releases
Date Fri, 19 Aug 2016 14:54:40 GMT
On Fri, Aug 19, 2016 at 4:27 PM, Raul Kripalani <raul@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" <claus.ibsen@gmail.com> wrote:
>
>> On Wed, Aug 17, 2016 at 4:12 PM, Raul Kripalani <raul@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.ibsen@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 <raul@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.ibsen@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 <raul@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

Mime
View raw message