The value proposition is awesome. But it's way too complex for a community to manage up to 130+ independent lifecycles.
On the other hand, as a user, I'd love to upgrade my Camel JMS component to a newer release without upgrading Camel as a whole. To pull in bug fixes, a particularly interesting feature, etc. As a prerequisite, we'd need a completely static API throughout 3.x that components can bind to. So I could run Camel 3.1 with camel-jms 3.2, for example. That said, taking a wild guess, most users won't run a mix'n'match deployment. If they use 20 components, they'll probably stick to the main version for most of them, except for when they need a very particular bug fix or feature in a given component. Only then will they consider upgrading that component. SNAPSHOT and nightly builds can help, but the handicap is that they are volatile releases. So you are never ever guaranteed to get the same binary from Maven Central at two different times. So my proposal is to create a "hotfix" procedure within the Camel community. If a Committer feels they have just committed an important fix which cannot wait for the next Camel release, they can push a hotfix release to Maven Central, e.g. camel-jms-3.2.1-HF-01. Performing such releases is at the full discretion of Committers, and of course, can be demanded by the community. WDYT? I don't know how feasible this is from the organisational viewpoint (who can perform a release, sync with Maven Central, etc.), but it looks like a solid solution for the real problem at hand: being able to push important component fixes to the community quickly and nimbly. If other committers feel similarly, we can find a way to make it work! Regards, *Raúl Kripalani* Apache Camel Committer Enterprise Architect, Program Manager, Open Source Integration specialist http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani http://blog.raulkr.net | twitter: @raulvk <http://twitter.com/raulvk> On Tue, Feb 19, 2013 at 7:16 AM, Henryk Konsek <hekon...@gmail.com> wrote: > Hi, > > 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 [1]. One on the issues > discussed during the previous IRC session was the question whether is > it possible to release components more frequently than core. > > I was wondering if we could introduce additional versioning for the > components based on the Maven version qualifiers [2] starting from > Camel 3. Qualifiers are fully supported by Maven. Versions comparison > and ranges work with qualifiers as well [3]. As far as I googled > Release Plugin can handle them correctly too (as well as > submodule-only release). > > 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 "Component Release"). > > What camel-cxf-3.0.0-CR-03 version would state is - this is the 3rd > version of the CXF component tested against the Camel 3.0.0 core. > > This approach will require us to decouple "components" 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. > > 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. > > What do you think? > > Best regards. > > [1] > http://camel.465427.n5.nabble.com/DISCUSS-CAMEL-3-0-weekly-IRC-chat-at-02-12-2013-7-00PM-8-00PM-CET-td5727462.html > [2] > http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-syntax.html > [3] > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution > > -- > Henryk Konsek > http://henryk-konsek.blogspot.com >
