jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: More frequent releases
Date Sun, 11 Sep 2011 08:40:36 GMT

Basically I am in favor of more frequent releases.

Yet, I still see a big issue in just cutting full-fledged releases,
keeping version numbers of all modules in sync. I think this will
confuse users down the road, particularly thos living in more modular
worlds such as OSGi. [And I am pretty sure I am repeating myself here ;-) ]


On 09.09.2011 14:21, Jukka Zitting wrote:
> Hi,
> It's nine months since we released Jackrabbit 2.2.0, so it's high time
> we push out the 2.3 release. I'll go through the remaining open issues
> and come up with a more concrete release plan based on the current
> status.
> Beyond the immediate concern of releasing Jackrabbit 2.3 I'd like to
> also address the larger issue of our release schedule. We're currently
> pushing out new releases from trunk at a rate of roughly one or two
> per year. I think that's too few as it allows the trunk to evolve
> quite a bit between successive releases and incurs a long delay
> between when a feature is added to trunk and when it goes out in a
> release.
> To solve this problem I suggest that we adopt a even/odd version
> numbering scheme for stable/unstable releases like the one used by the
> Linux kernel. The latest trunk would always have an odd version number
> (2.3, 2.5, etc.) and we could cut unstable releases like 2.3.0, 2.3.1,
> etc. from it as often as we like since they'd come with a warning
> against production use. Then at selected times we can create stable
> maintenance branches (2.4, 2.6, etc.) from the trunk and cut stable
> releases from them for production use.
> With such a release strategy we could be pushing out releases from the
> trunk pretty much whenever anyone wants or needs one. I'd like to see
> us doing at least one such unstable release per month going forward.
> Increased frequency of such unstable releases would also reduce the
> pressure on making production-ready stable releases. We could target
> at something like just one stable minor release per year (plus of
> course any patch releases from the maintenance branches).
> BR,
> Jukka Zitting

View raw message