Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of willem.jiang@gmail.com
 designates 209.85.160.42 as permitted sender)
Date: Wed, 20 Feb 2013 10:34:39 +0800
From: Willem jiang <willem.jiang@gmail.com>
To: dev@camel.apache.org
Message-ID: <7061908EAA7B403990753287C4CCE422@gmail.com>
In-Reply-To: 
 <CALhQg-Z0O1RM7rB61MbdG97+kWMnRXstM2vCgs837sSQOf=6hQ@mail.gmail.com>
References: 
 <CALhQg-Z0O1RM7rB61MbdG97+kWMnRXstM2vCgs837sSQOf=6hQ@mail.gmail.com>
Subject: Re: [Camel 3 discussion] Components releases
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

It's hard to track all the version of camel-component and it will make th=
e release process every complex, if we don't release it with the core. So=
 I cannot agree with this proposal. =20

As you know In ServiceMix we have lots components which have not direct d=
ependency with the core, so we break this components out and release them=
 separately. Before we do the servicemix release, we need to release the =
kernel ( which is Karaf now), bundles, components, features. Because the =
Apache 3 days release vote policy, a whole release will take for weeks. I=
t holds the release for years, and we can see ServiceMix can barely do on=
e major release per year.

In Camel we provides the patch release after the major release, I think i=
t is not a big deal if we need to meet the needs of camel component relea=
se. BTW, the patch release is also slow down the trunk development, as it=
 is time consuming work that we need to merge back the patch to assume it=
 works in different branch. =20

-- =20
Willem Jiang

Red Hat, Inc.
=46useSource is now part of Red Hat
Web: http://www.fusesource.com =7C http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) =
(English)
          http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang =20
Weibo: =E5=A7=9C=E5=AE=81willem


On Tuesday, =46ebruary 19, 2013 at 3:16 PM, Henryk Konsek wrote:

> Hi,
> =20
> Unfortunately I won't be able to join the IRC session today as I need
> to hire myself as a babysitter this evening. However I would like to
> discuss some subject that come up recently =5B1=5D. One on the issues
> discussed during the previous IRC session was the question whether is
> it possible to release components more frequently than core.
> =20
> I was wondering if we could introduce additional versioning for the
> components based on the Maven version qualifiers =5B2=5D starting from
> Camel 3. Qualifiers are fully supported by Maven. Versions comparison
> and ranges work with qualifiers as well =5B3=5D. As far as I googled
> Release Plugin can handle them correctly too (as well as
> submodule-only release).
> =20
> The versioning of the core would stay the same. Whenever we release
> core, we release all the components as well - this doesn't change as
> we want to guarantee the users that we have tested all components
> against the latest core. However we could change the versioning of the
> components to be qualified as follows - camel-cxf-3.0.0-CR-01 (where
> CR qualifier stands for =22Component Release=22).
> =20
> What camel-cxf-3.0.0-CR-03 version would state is - this is the 3rd
> version of the CX=46 component tested against the Camel 3.0.0 core.
> =20
> This approach will require us to decouple =22components=22 module from =
the
> core the same was as camel-extra is. To be exact components should be
> dependent on the release version of camel-core instead of SNAPSHOT.
> And we should perform core release separately before the components
> release.
> =20
> I have never worked with qualified releases so I'm not sure if this
> approach won't be the release hell, but I think we could consider this
> option as Maven offers qualifiers out of the box. This may be a nice
> option to reduce time needed to deliver the latest artifacts to the
> end users.
> =20
> What do you think=3F
> =20
> Best regards.
> =20
> =5B1=5D http://camel.465427.n5.nabble.com/DISCUSS-CAMEL-3-0-weekly-IRC-=
chat-at-02-12-2013-7-00PM-8-00PM-CET-td5727462.html
> =5B2=5D http://www.sonatype.com/books/mvnref-book/reference/pom-relatio=
nships-sect-pom-syntax.html
> =5B3=5D http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and=
+Conflict+Resolution
> =20
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com