More frequent releases

[Jukka Zitting <ju...@gmail.com>]

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

AW: More frequent releases

[KÖLL Claus <C....@TIROL.GV.AT>]

+1 from me.

Looks good to me to have such a realease strategy

greets
claus

Re: More frequent releases

[Jukka Zitting <ju...@gmail.com>]

Hi,

Sounds like we have rough consensus. I'll follow up with the 2.3.0
release plan based on this.

On Sun, Sep 11, 2011 at 10:40 AM, Felix Meschberger <fm...@gmail.com> wrote:
> Yet, I still see a big issue in just cutting full-fledged releases,
> keeping version numbers of all modules in sync.

I hear you, but for now I don't think we have the release management
muscle to properly manage too many concurrent release cycles. We tried
this during 1.4 and 1.5 with the Jackrabbit Commons initiative, but
the effort pretty much died down due to the required extra overhead.
Unless people are willing to invest the extra effort I suggest we
stick with the synchronized release model for now.

Instead, see JCR-3073 for an effort to better manage and version the
public API packages within Jackrabbit. That should address the needs
of OSGi deployments with less overhead for us.

[1] https://issues.apache.org/jira/browse/JCR-3073

BR,

Jukka Zitting

Re: More frequent releases

[Felix Meschberger <fm...@gmail.com>]

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
>