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
