Bugzilla branch lifecycle proposal

[Dave Miller]

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/