Re: Update on 2016 Firefox Release Schedule

I'm also a huge fan of this optimization.  I understand Dave's concern, and
I think we need to keep an eye on things. However, I also believe that a
perfectly fixed schedule has caused considerable strain and pressure over
the last four years, which has contributed to a significant number of
 *.0.1 releases.  I'm hopeful that this relatively small tweak will help us
better manage these releases.

One thing that is implied from the release schedule, but not explicitly
addressed, is the idea of making the December release a critical bugfix
release (I'd look at that as 50.1 vs. 50.0.1), rather than a major release
with new features. Most (probably all) of our commercial partners have
production code lockdowns from around mid-November through January 1st,
given the critical commercial importance of the holiday season.  Anything
we can do to reduce risk/impact for web/add-on compat at that time of year
will help our users and the Web as a whole.

The second implication of the critical bugfix cycle is that ESR would
effectively shift to an annual cadence, which I believe will be positively
received by the enterprise community.  Solid, predictable updates would be
a win for those folks.

Thanks to everyone involved in pushing this forward, I think it's a great
step forward.

-- Mike

On Thu, Feb 4, 2016 at 6:19 PM, Andrew McKay <[email protected]> wrote:

> I think this new schedule is great.
>
> But as someone new to the process I saw a lot of pain shipping Firefox 43
> between Mozlando and Christmas, people were finding mission critical issues
> and trying to fix them, whilst being on holiday. The pressure and stress I
> saw often led to the question"exactly why do we need to ship right now
> instead of waiting a couple of weeks?".
>
> It seems the cost to the team, the developer community and Firefox users
> isn't worth it unless we can get that shipping smoother and more reliable.
> The real answer is to find a way to ship Firefox easier and smoother and I
> think everyone is working towards that.
>
> On Thu, Feb 4, 2016 at 5:10 PM, Dave Herman <[email protected]> wrote:
>
> > I'm concerned about the suggestion that we could start delaying trains,
> > especially on an ad hoc basis. Trains work because of predictability and
> > frequency.
> >
> > It's hard for me to quite understand the rationale behind varying the
> > schedule, but if it's because of things like quality issues, say, from
> > shipping features before they're adequately tested, then delaying trains
> > will actually exacerbate the problems, not fix them. The less people can
> > depend on trains, the more pressure they will feel to ship early, which
> is
> > precisely the thing you were trying to address. If the problem with
> > holidays and such is that people are trying to cram features in at the
> last
> > minute, then again, delaying trains and making them less predictable will
> > exacerbate that.
> >
> > Regardless of the rationale, adding variability and uncertainty into the
> > train system works directly at odds with what it has been so successful
> at
> > achieving -- not just for Firefox, but for Chrome and Rust, for example.
> > This isn't a small thing: giving credit where due, I see trains as the
> best
> > thing Chrome ever did for the web. It's been one of the biggest drivers
> in
> > pushing the platform forward. I would hate to see us regress in our
> > contribution to that part of our mission.
> >
> > Dave
> >
> > On Thu, Feb 4, 2016 at 12:50 PM, Lawrence Mandel <[email protected]>
> > wrote:
> >
> > > Four years ago Mozilla moved to a fixed-schedule release model,
> otherwise
> > > known as the Train Model
> > > <https://blog.mozilla.org/channels/2011/07/18/every-six-weeks/>, in
> > which
> > > we released Firefox every six weeks to get features and updates to
> users
> > > faster and move at the speed of the Web. We studied the process
> carefully
> > > and learned a lot. We have also identified additional areas for
> > improvement
> > > and it’s time we iterate again.
> > >
> > > We are moving to a variably scheduled six-to-eight week release cycle
> for
> > > Firefox. With this new release cycle, we will deliver the same number
> of
> > > releases per year but gain a few significant benefits over the previous
> > six
> > > week fixed model.
> > >
> > > For example, we will now be able to adjust release dates to respond to
> > > emerging user and market needs and provide at least six working weeks
> for
> > > every release. We also want to help support the well-being and
> > > connectedness of our global Mozilla community by specifically allowing
> > time
> > > for holidays.
> > >
> > > You’ll find the 2016 Firefox release schedule listed below and in the
> > > following Wiki <https://wiki.mozilla.org/RapidRelease/Calendar>.
> > >
> > >
> > > This note has also been posted to the Future of Firefox blog
> > > <
> > >
> >
> https://blog.mozilla.org/futurereleases/2016/02/04/update-on-2016-firefox-release-schedule
> > > >
> > > .
> > >
> > >
> > > 2016 Firefox Release Schedule
> > >
> > > 2016-01-26 - Firefox 44
> > >
> > > 2016-03-08 - Firefox 45, ESR 45 (6 weeks cycle)
> > >
> > > 2016-04-19 - Firefox 46 (6 weeks cycle)
> > >
> > > 2016-06-07 - Firefox 47 (7 weeks cycle)
> > >
> > > 2016-08-02 - Firefox 48 (8 weeks cycle)
> > >
> > > 2016-09-13 - Firefox 49 (6 weeks cycle)
> > >
> > > 2016-11-08 - Firefox 50 (8 weeks cycle)
> > >
> > > 2016-12-13 - Firefox 50.0.1 (5 week cycle, release for critical fixes
> as
> > > needed)
> > >
> > > 2017-01-24 - Firefox 51 (6 weeks from prior release)
> > >
> > > Note: Firefox ESR will continue to ship point releases on the same day
> > that
> > > Firefox ships.
> > >
> > >
> > > Lawrence
> > > _______________________________________________
> > > dev-planning mailing list
> > > [email protected]
> > > https://lists.mozilla.org/listinfo/dev-planning
> > >
> > _______________________________________________
> > dev-planning mailing list
> > [email protected]
> > https://lists.mozilla.org/listinfo/dev-planning
> >
> _______________________________________________
> dev-planning mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-planning
>
_______________________________________________
dev-planning mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-planning