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" <r...@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 <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 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 <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 >>> >> >> >
