Hi Henry, >From what I understood, you were suggesting a different versioning model for components at the POM level.
My suggestion was to keep the current POM versioning model, but just create a "component hotfix" repository where we can publish "tags" of components upon demand. To continue with my example, the version on camel-jms would remain intact, following exactly camel-core (or the future camel-api, if that idea prospers). We'd just run mvn release to tag and publish hotfix releases for a component. Concerning the Maven versioning policy, I don't like components having a different version nomenclature than the rest of Camel. I'd much rather make all Camel elements use "-GA" to indicate General Availability, just like Spring do. 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 10:04 PM, Henryk Konsek <hekon...@gmail.com> wrote: > Hi Raul, > > > 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. > > This is essentially what I've proposed. :) > > But keep in mind that due to the Maven versioning resolution [1] we > need to append qualifier (for example -HF-01) to the first released > version of the artifact. Because for Maven camel-jms-3.2.1-HF-01 is > older than camel-jms-3.2.1. We need to be nice for Maven in this > regards because many plugins relay on the proper versioning strategy. > That's why I proposed to release components with -CR-01 qualifier > already in place. > > > The value proposition is awesome. But it's way too complex for a > community > > to manage up to 130+ independent lifecycles > > There are no so independent as they are bounded to the borders of core > releases. The core version is the common denominator here. > > > That said, taking a wild guess, most users won't run a mix'n'match > > deployment. > > There is no mixing here, as component is tested and released again > certain version of core. Keep in mind that when core updates, we will > perform full release and "reset" the components qualifiers. There is > no ambiguity here - it is clear that camel-jms-3.2.1-CR-xx is supposed > to be deployed only with camel-core 3.2.1. > > > 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. > > Deploying SNAPSHOTS or nightly builds to the production is asking for > trouble. That's why we (users) want independent versioning for > components. > > [1] > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution > > -- > Henryk Konsek > http://henryk-konsek.blogspot.com >
