Why do all Camel components have the same version number?

[pmcb55 <mc...@dnb.com>]

I'm intrigued by the versioning strategy used for Camel components. I'm
wondering why all 80 (or whatever) Camel component JARs share the same
version number. I assume very few of these components have code changes
between releases (since Camel is very stable), so why not only bump up their
version numbers when that component's code actually changes?

What happens if, hypothetically, a single Camel component needs a new
version (say due to a critical bug fix), but no other components change, nor
does Camel Core change. Would Camel still release a new version of all 80
Camel Components, and a new version of Camel Core, just to get this new
critical component version out...?

Or is this just a convenience mechanism (i.e. if I use 5 Camel components, I
just have to define one Maven property for the version of all 5, rather than
hard-coding specific version numbers for each component)? Could someone
point me to an argument in favour of this model, or even just a
justification (and the trade-offs), since my understanding of version number
semantics is that the version number of a JAR only changes if the code
itself has changed...?

Thanks,

Pat.




--
View this message in context: http://camel.465427.n5.nabble.com/Why-do-all-Camel-components-have-the-same-version-number-tp5730658.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Why do all Camel components have the same version number?

[Chris Geer <ch...@cxtsoftware.com>]

See this thread:
http://camel.465427.n5.nabble.com/Camel-3-discussion-Components-releases-td5727764.html


On Wed, Apr 10, 2013 at 11:00 AM, pmcb55 <mc...@dnb.com> wrote:

> Yep - I get that Don, and I agree that that is certainly a benefit. I'm
> just
> wondering if it's worth the cost of re-releasing a new version of
> 'everything' if I only want to make a small (but maybe critical) change to
> one small isolated component that no other part of the system depends
> on...?
>
> Maybe I'm worrying too much about this 'cost' - it seems to work great for
> Camel, but I'm just wondering about any other 'costs' associated with this
> approach...?  So do you know of any documentation, or articles, or guidance
> on general versioning strategy for generic framework code (i.e. code made
> up
> of multiple independent, but somehow related, libraries)?
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Why-do-all-Camel-components-have-the-same-version-number-tp5730658p5730673.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>

Re: Why do all Camel components have the same version number?

[pmcb55 <mc...@dnb.com>]

Yep - I get that Don, and I agree that that is certainly a benefit. I'm just
wondering if it's worth the cost of re-releasing a new version of
'everything' if I only want to make a small (but maybe critical) change to
one small isolated component that no other part of the system depends on...?

Maybe I'm worrying too much about this 'cost' - it seems to work great for
Camel, but I'm just wondering about any other 'costs' associated with this
approach...?  So do you know of any documentation, or articles, or guidance
on general versioning strategy for generic framework code (i.e. code made up
of multiple independent, but somehow related, libraries)?



--
View this message in context: http://camel.465427.n5.nabble.com/Why-do-all-Camel-components-have-the-same-version-number-tp5730658p5730673.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Why do all Camel components have the same version number?

[Donald Whytock <dw...@gmail.com>]

I assume a part of each significant release is testing all the components
against the core.  So even if the component itself hasn't changed, it can
be said to be compatible with the current core, and thus gets the same
version number as the core.

Don


On Wed, Apr 10, 2013 at 8:57 AM, pmcb55 <mc...@dnb.com> wrote:

> I'm intrigued by the versioning strategy used for Camel components. I'm
> wondering why all 80 (or whatever) Camel component JARs share the same
> version number. I assume very few of these components have code changes
> between releases (since Camel is very stable), so why not only bump up
> their
> version numbers when that component's code actually changes?
>
> What happens if, hypothetically, a single Camel component needs a new
> version (say due to a critical bug fix), but no other components change,
> nor
> does Camel Core change. Would Camel still release a new version of all 80
> Camel Components, and a new version of Camel Core, just to get this new
> critical component version out...?
>
> Or is this just a convenience mechanism (i.e. if I use 5 Camel components,
> I
> just have to define one Maven property for the version of all 5, rather
> than
> hard-coding specific version numbers for each component)? Could someone
> point me to an argument in favour of this model, or even just a
> justification (and the trade-offs), since my understanding of version
> number
> semantics is that the version number of a JAR only changes if the code
> itself has changed...?
>
> Thanks,
>
> Pat.
>
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Why-do-all-Camel-components-have-the-same-version-number-tp5730658.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>