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
