Re: Bugzilla branch lifecycle proposal

Looks good to me.

I'd encourage thoughts on how to be on par with Firefox, Chrome and
Cpanel-like products in terms of self-updates. To get there longterm we
need to discuss the strategy now.

On Thursday, April 23, 2015, Dave Miller <[email protected]> wrote:

> 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/
>
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/[email protected]>
>