Hi 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 ;-) ] Regards Felix 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). > > WDYT? > > BR, > > Jukka Zitting >
