Bugzilla branch lifecycle proposal

[Dave Miller]

For the record, I like this plan.  Our release cycles tend to take long
enough these days that it's a Really Long Time™ before a release gets EOLed.

Dave Miller wrote:
> The following proposal was on the agenda for our Project meeting
> yesterday, but because it was the only thing on the agenda, and we felt
> it warranted a larger audience than those in attendance at the meeting,
> we opted to call off the meeting and post it here.
> 
> ----------------
> Proposal (from LpSolit) : Reduce the number of supported branches.
> Instead of waiting for {N+3}.0 to be released before N.x reaches EOL, I
> propose N.x reaches EOL 4 months after the release of {N+2}.0. Concrete
> example: instead of waiting for 6.0 to be released before 4.2 reaches
> EOL, I propose 4.2 reaches EOL 4 months after the release of 5.0
> (probably means around 5.0.2). Two major reasons for that: 1) when we
> are closer from the next major release, having to think about very old
> branches is a pain (think about security backports, QA, maintain old
> repo alive, release stuff), and 2) data shows that installations still
> running old versions of Bugzilla generally do not care about upgrading
> (e.g. install 4.0.1 and that's it; never upgrade to 4.0.17, so why
> should we bother that long?).
> ----------------
> 
> Since LpSolit hasn't posted it here himself yet I figured I'd get it out
> there.  Discuss.
> 

-- 
Dave Miller http://www.justdave.net/
IT Infrastructure Engineer, Mozilla http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/