jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: jackrabbit-core 1.4.2 release plan
Date Fri, 14 Mar 2008 08:48:02 GMT

Am Donnerstag, den 13.03.2008, 16:17 +0200 schrieb Jukka Zitting:
> I'd personally like to keep a hard line on release versioning, i.e.
> only bug fixes in patch releases and if needed do more frequent minor
> releases for other improvements and new features.

I can live with both solutions. What is paramount to me, is that we can
get more frequent releaes of components. I would even go a step further
and say, that sometimes it makes sense to create a release even in the
case of enhancements.

Whatever we do: version numbers of components will diverge and we should
not fall into the trap of raising all version numbers to the same
numbers just because of a minor release. This would really be
problematic to dependency management - as I always said ;-)

> WDYT, should we be more relaxed in what goes into each release, or
> should we keep up the strict release policy? In the latter case I
> think we should go further down the line of component releases and
> allow releases like jackrabbit-core 1.5 whenever needed regardless of
> the status of other components.

Once consequence we should certainly not get out of sight: Currently the
parent pom not only manages dependencies external to Jackrabbit - such
as lucene - but also internal dependencies between different components
of Jackrabbit. 

Likewise, each component just inherits the version number of the parent

Both of these setups will have to be changed no matter what: Each
component defines its own version number, which is always a SNAPSHOT
version number - except for tagged versions - and dependencies between
components are always set to the minimal released number of the
depending component. This way we can also better managed release

If we just raise the dependencies between Jackrabbit Components each
time a release happens, this amounts to a nightmare of not being able to
track the actual dependency requirement !


View raw message