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
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-snapshots@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_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
