Re: Bugzilla branch lifecycle proposal

I also support this. Although I think it might be better to extend to 4
months instead of 6 given how long our release cycles have been
historically.

dkl

On Thu, Apr 23, 2015 at 1:20 AM, Dave Miller <[email protected]> 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/
>
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/[email protected]>
>



-- 
David Lawrence
[email protected]
bugzilla.mozilla.org