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