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 > 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. >
That is actually not entirely accurate. The 2.18-SNAPSHOT is only in use until the 2.18.0 release. Then any patch releases 2.18.1, 2.18.2 and so on, are using 2.18.1-SNAPSHOT 2.18.2-SNAPSHOT etc. > 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 >> -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
