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 >> > >
