Hi,
We went down this path in a rather large project and it didn't end up
working out. The follow up on the mailing lists from people who weren't
using a dependency manager and were continually confused by version
numbers was a real pain.
In the end we went back to a single version number for the entire
project and did a synchronized release of the entire thing when enough
significant changes had been accumulated. Naturally some people choose
to run bleeding edge builds of some components to get around their
immediate problems before the next synchronized release.
We use Ivy for dependency management so it makes little difference to us
if each jar is numbered independently or the same as the overall
package, we're still able to pull down what X.Y.Z should be as a whole.
So I personally sit on the fence on this one but thought I'd share an
experience which will hopefully help you guys make up your mind.
Bradley
Jukka Zitting wrote:
Hi,
On Tue, Jul 22, 2008 at 3:30 PM, Alexander Klimetschek <[EMAIL PROTECTED]>
wrote:
Generally I agree, but I know that something like jackrabbit 1.4.6
containing a 1.4.5 core jar would be very confusing when users report
a problem. Couldn't we make an exception that the most important
component jackrabbit-core always gets the same version number as the
overall release - which would imply that sometimes core gets a version
number increase without an actual code change.
I guess we could do that. And in fact in any case the core version
would need to be upgraded whenever any of the core dependencies
(jcr-commons, spi-*, etc.) are modified, so the number of "extra" core
version increases would probably remain quite rare.
BR,
Jukka Zitting
