jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bradley Beddoes <bedd...@intient.com>
Subject Re: Component releases, proposed solution
Date Tue, 22 Jul 2008 13:21:04 GMT
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 <aklimets@day.com> 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


Mime
View raw message