
Firefox moving to 4 week releases - rebelwebmaster
https://hacks.mozilla.org/2019/09/moving-firefox-to-a-faster-4-week-release-cycle/
======
lucb1e
I've always wondered this: why release on a schedule at all? If people demand
a certain new feature ("[this will] bring you new features more quickly"), it
can just be brought out as it's ready, instead of having to wait an average of
3 (now 2) weeks before it can be released? And why does this have to increment
the major version, since when is every single update backwards incompatible?

~~~
fluffything
Firefox ships ~100 binaries for 100 different targets, from mobile phones, to
desktops, tablets, ... x86, arm, sparc, ppc, riscv, ... X linux, windows,
macos, freebds, openbsd, netbsd, .... X arch linux, debian, ubuntu ..

At some point you need to say this is what we want to ship, and branch, and
make sure that not only all tests pass, but that the installers work, run the
benchmark suite that might not be run on every PR, make sure the updates work
on all systems, appstores, etc. Accept new patches to fix bugs, etc.

I suppose they might have a release team that does nothing but releases, and
if creating a full release takes a week (no idea how long it takes honestly),
then maybe they could release each week.

But I don't think they can release a new version every day, because probably
running their whole CI takes longer.

E.g. before shipping a version of Rust, the RC is used to build and run tests
of all packages in the Rust package repository. This takes 4 full days. One
could probably throw money at the problem and speed it up, but at least right
now, releases just cannot technically happen faster, unless you are willing to
compromise on quality.

~~~
aquabeagle
Mozilla only provides binaries for Linux 32-bit, Linux 64-bit, macOS, win32,
and win64:

[http://ftp.mozilla.org/pub/firefox/releases/69.0/](http://ftp.mozilla.org/pub/firefox/releases/69.0/)

All of the various Linux distributions just repackage those binaries. iOS and
Android are distributed only through the App Store and Google Play.

The BSDs and other ("tier 3") platforms have to compile from source and
distribute their own packages:

[https://developer.mozilla.org/en-
US/docs/Mozilla/Supported_b...](https://developer.mozilla.org/en-
US/docs/Mozilla/Supported_build_configurations)

~~~
kingofpandora
> _All of the various Linux distributions just repackage those binaries._

Source please.

Never mind, it's simply wrong so don't even worry about it!

~~~
ajsnigrutin
Gentoo does it for firefox-bin:

/usr/portage/www-client/firefox-bin/firefox-bin-69.0.ebuild

    
    
        MOZ_HTTP_URI="https://archive.mozilla.org/pub/mozilla.org/${MOZ_PN}/releases/"
        ...
        SRC_URI="${SRC_URI}
            amd64? ( ${MOZ_HTTP_URI%/}/${MOZ_PV}/linux-x86_64/en-US/${MOZ_P}.tar.bz2 -> ${PN}_x86_64-${PV}.tar.bz2 )
            x86? ( ${MOZ_HTTP_URI%/}/${MOZ_PV}/linux-i686/en-US/${MOZ_P}.tar.bz2 -> ${PN}_i686-${PV}.tar.bz2 )"

~~~
brennebeck
Doesn’t gentoo essentially do that for (most?) everything?

~~~
moviuro
Only massive packages (firefox, chromium, KDE, Gnome, etc.). The entire
promise of gentoo is the opposite: fine-tuning and local ~~heater~~
compilation.

------
Ididntdothis
I don’t really like these quick release cycles. When things get released every
year or half year I have the time to read about the changes but if I work with
several packages that release all the time I don’t even have the time to read
about the changes.

I also think that quality tends to suffer. Over the last two years windows 10
has released several buggy updates that caused our in house apps to stop
working.

~~~
bengoodger
Quality can be worse in a long-time cycle project: \- Engineers are motivated
to slam their feature in, because if they miss the train the next one's not
for 12 months. \- You get one moment per year to connect with your customers &
understand how well/not well your changes worked. This means either riskier
things happen or that innovation slows to a crawl.

My 2 cents, speaking from some experience working on long time cycle projects
and shorter cycle projects.

~~~
kerkeslager
Why cycles at all? Why not look at what features have been integrated, whether
they make up a set that you want to release, and then release?

Neither long cycles nor short cycles make any sense. Some features take a long
time to develop, some take a short time to develop. Sometimes features that
take a long time to develop aren't user-facing enough to be worth releasing
for, and sometimes a quick fix has a huge impact that's worth a release, like
a patch for a vulnerability that's actively being exploited by a spreading
malware. Features simply don't line up with a single length of time. The
problem isn't long or short cycles, it's cycles.

~~~
JoshTriplett
Because regular, predictable releases mean that developers know they can
always "catch the next train", _and_ users know they can plan around
predictable upgrade schedules.

~~~
kerkeslager
> Because regular, predictable releases mean that developers know they can
> always "catch the next train"

This is an argument for _frequent_ releases, not _regular, predictable_
releases.

> users know they can plan around predictable upgrade schedules.

I'm not sure this is actually how users plan upgrades.

The majority of individuals probably never turn off the auto-update flag.
Planning doesn't enter the equation.

For organizations, my guess is that most organizations will _try_ to build
their upgrade process around security, but the reality will rarely be so
clean. When I worked in IT we'd get computers into our shop that hadn't been
updated. Period. We'd upgrade our provisioning images when there was a notable
security patch, and besides that, we just would run updates on every machine
every week at 2am Sunday night: that way it didn't interfere with users, but
if something went wrong, we were on it with the full team first thing Monday
morning. But if machines were turned off or whatever, they wouldn't run the
updates. At no point did we ever even check the release schedule of a piece of
software: the updates happened on our time, and theirs was irrelevant.

I didn't work in IT for very long, though, so someone with more IT experience
should correct me if I'm wrong.

------
chaosmachine
According to my calculations, this means Firefox 100 will be released on
2022-03-08.

~~~
zepearl
In general I like more the classic/old way of versioning the releases, like
for example "1.2.2" which has some embedded meaning of what is changing (e.g.
<major_change>.<minor_change>.<bugfix>) which hints at how potentially
dangerous an upgrade might be or if some new exciting stuff has been included.
Jumping directly from 10 to 11 to 12 leaves me clueless without reading all
release notes :(

~~~
Someone1234
Semantic versioning is useful. Unfortunately the marketers have taken over and
there's a numbers race going on.

~~~
sroussey
Semantic versioning is useful for libraries. Let useful for consumer apps.
2019-10 says more than 76.0.0

~~~
masklinn
> 2019-10 says more than 76.0.0

Neither says anything _useful_. 2019-10 is no more actionable or informative
than 76.0.0. That 2019-10 was released in october 2019 is meaningless
information and only "more" in the "babble" sense.

~~~
fnord123
2014-04 is absolutely actionable for a browser.

~~~
MaulingMonkey
2014-04 is actionable for a _lot_ of stuff - "unpatched" or "unmaintained"...

------
lvh
There's an incidental benefit here. There's at least one system (I think Duo +
Okta?) which, when configured to check if your browser is out of date, makes a
logic error. It should check if your browser is the most recent, and, if it
isn't, if the _new release_ is over N days old. Instead, it checks if your
browser is the most recent, and if it isn't, if the _old release_ is over N
days old. So, if you run Firefox and you get it from your Linux distribution,
that breaks during the two days or so in between a new release and e.g. Fedora
shipping it.

~~~
gruez
Must be fun for ESR users, because ESR reports the base version regardless of
when it was patched. So ESR 60.9 (released alongside 69, still supported),
would look a year out of date.

~~~
yjftsjthsd-h
Yeah, I especially like that Mozilla's own pages will tell me my browser is
out of date when running ESR:)

------
ShakataGaNai
The thing that scares me about this change is that it seems like the only
reason they are doing it is "we’ve had many requests to take features to
market sooner.". Where as the rest of the blog entry is to assuage our fears
and otherwise placate everyone that things won't explode.

I don't know if 4 weeks is or isn't the right answer (after all some SaaS
companies update dozens of times a day), but I know that I tend to leave my
browser windows open until it crashes or the computer reboots. While I don't
regularly use Firefox right now, I can imagine that I could skip entire
versions with this behavior.

~~~
hairui
On firefox I get a thing that says "we need to update really quick, sorry!"
You click "ok" and the browser restarts and reloads everything. Seems to be a
pretty good solution to the problem you describe.

------
Mathnerd314
For comparison, Chrome updates "every two-three weeks for minor releases, and
every six weeks for major releases".

I guess Beta is moving to daily releases? I suppose it's good, generally I
have to restart Firefox once a day for resource leaks and restarting through
the update UI is easier than opening the browser console.

I was using Nightly for a while but it turns out that even daily updates
aren't fast enough for that. If a new patch breaks something, typically the
offending patch isn't backed out and it takes 6-12 hours to get fixed, meaning
the fix isn't available in the next nightly and you have to suffer for several
days.

~~~
muizelaar
Have you filed a bug about the resource leaks?

~~~
Mathnerd314
I looked a while ago and it seems to be due to some of the webextensions I
have installed, probably uBlock Origin but I can't be sure (28 extensions).
Basically some things get cached that don't need to be, and then the cheap
5400rpm disk drive makes the browser stutter swapping between tab content
processes.

I'm waiting for the hard drive to die so I can justify getting a new SSD or
laptop, which I'm pretty sure will solve the problem, so no, I haven't filed a
bug.

~~~
gorhill
> probably uBlock Origin but I can't be sure (28 extensions).

Why "probably"? I fail to see how uBO is related to "things get cached that
don't need to be".

~~~
Mathnerd314
It's the largest extension I have installed, 2.5 MB. It could also be Stylus
or Tampermonkey, but I saw uBO in the performance profiles I made, running the
JIT and blocking some threads.

The main issue is capturing a decent profile, the lag caused by the profiler
makes it hard to trust anything.

------
JohnFen
I think this is sad news, but that's because I view the current "rapid
release" trend and being, on the whole, a bad thing for everyone. It decreases
software quality, decreases stability, and increases hassle and stress for
everyone from developers to users.

~~~
jillesvangurp
It actually does the opposite. It's big, infrequent releases that are risky,
less stable. Users update automatically; they barely notice it today. Most non
techie users have no idea that it is happening. A few years go we had these
big bang releases with browsers, operating systems, etc. and things were much
worse. Anytime you unleash millions of new lines of code on users it's almost
guaranteed that there will be some stuff wrong with it that your months or
years of testing did not catch.

Short release cycles mean smaller deltas and it also makes postponing the
merging of changes to the next release is less disruptive. Merging things when
they are ready instead of merging them to early to not miss some big releases
is better.

Another reason smaller deltas is better is that risk does not scale with a
linear relation relative to the amount of change but more like a quadratic or
exponential relation. So, the less changes you introduce with a release, the
less effort you need to ensure all is well. The testing over head increases
massively with the amount of change since there are more combinations of
things that can go wrong that all need testing. Finally, with the time
increasing between the introduction of issues and people finding them, the
complexity of analyzing them in the presence of other bugs becomes harder.
Shorter feed back cycles are great for finding issues early.

Currently from nightly to release takes about 12- 16 weeks (assuming 6-8 week
cycles). With this change, it will reduce to about 8 weeks. That's still two
months of exposure to large group of nightly testers and an even larger group
of beta testers.

~~~
JohnFen
Yes, I'm well aware of the arguments in favor. It's just that I don't see it
playing out much in the real world. In my experience (on the whole -- there
are exceptions), rapid released software tends to be of lower quality.

Even if that weren't true, though, rapid release means a lot more updates, and
updates are a pain in the butt.

~~~
nickm12
Can you give concrete examples? For the software I use that is on a rapid
release schedule, (Firefox, Chrome, Dropobox, probably others I'm not even
aware of) I don't notice any sort of quality issue. The only "pain in the
butt" is having to restart my browser.

------
iagooar
Wrong decision. Nobody wants to update their browser this frequently, and the
release overhead is a constant factor. So you're basically having a lot less
productive time where you actually produce value. But hey, not my call I
guess.

~~~
pingyong
>Nobody wants to update their browser this frequently

Uhh really? Pretty sure "most people" don't even notice when their browser
updates.

~~~
Grue3
I almost never restart Firefox, and having a pop-up nagging me to update sucks
a lot. Sometimes I have to look at it for many weeks straight before Firefox
eventually eats all the RAM and I have to restart it.

~~~
diffeomorphism
Clicking close and then clicking restore session takes 5 seconds or so. Why
are you "almost never" restarting?

------
KuhlMensch
This is great news. I recently started using Firefox (out of principle
mainly). I find it pretty unstable, and whatever needs to be done to grease
the bug-fix chutes - so be it!

------
ksec
Please Correct me if I am wrong.

"We’re adjusting our cadence to increase our agility, and bring you new
features more quickly. "

Does having faster release cycle really means having new features more
quickly? The original 6-8 Weeks are already pretty damn fast. So I this pcs as
marketing to general new site rather than technical.

Firefox, ( And Google Chrome ) already has Alpha and Beta Channels with fairly
large number of audience testing it in real world. And features requires time
to think, design, bake, tested in real world and refine, having a few more
releases in between those process doesn't make the features come out any
quicker.

~~~
jonathankoren
Under a 6-8 week release cycle, it takes 12 to 16 weeks for code to go from
Nightly to Release assuming it rides the train and is not uplifted to Beta.
That is not fast.

Furthermore, the audiences for each of these channels are different, with
Nightly being much more tech centric early adopters. While you do some testing
in the prerelease channels, you main experimentation is going to have to wait
until the code hits release.

------
tanchoux
4 week releases will create 13 versions by year. We will use Firefox 211 in
2030 (if they don't change rules).

------
efiecho
Oh no, not this. Every new release means hours spent on rebasing patches,
investigating why the new version won't compile and then create more patches.
When Firefox finally builds, I now have to find out what they have
removed/changed that worked fine before, and what new crap that should be
disabled in about:conf. I need LESS of this, not more..

~~~
untog
You're not obliged to update every four weeks. Why not continue updating as
often as you currently do?

~~~
efiecho
There will usually be many security fixes with each new release, so I have no
choice.

~~~
untog
So surely more frequent releases is a good thing: you're getting security
updates quicker.

------
ninguem2
Why do I seem to get a firefox update on ubuntu on a daily basis?

~~~
swebs
Security updates need to be released ASAP.

------
sekoidd
should i use firefox or chrome?

------
dungdev
Hmmmm. I don’t really like these quick release cycles

------
esfandia
As a user I also now need to keep up with the updates more frequently. Either
deal with a more frequent risk of getting an update I don't like, or get
nagged more frequently with annoying pop-ups to update if I don't want to, or
turn off everything and miss out on the critical security updates.

~~~
I_AM_A_SMURF
Just switch to ESR if you don't want constant updates?

~~~
cpeterso
Firefox ESR still receives updates on the same schedule as regular Firefox.
The ESR updates are just limited to security fixes, so ESR will still download
minor updates but you'll only see big changes once a year for major updates
(like Firefox ESR 60.8 -> 68.0).

------
ken
> We’re adjusting our cadence to increase our agility, and bring you new
> features more quickly. In recent quarters, we’ve had many requests to take
> features to market sooner.

Mozilla has been tweaking their process forever, but all of it is for naught
if they don't work on what users want. The latest FF brags "we are shipping a
new “New Tab” page experience that connects you to the best of Pocket’s
content", while standard keyboard shortcuts have been broken for well over 10
years. This is not a problem with their release cadence.

Users have a curious way of asking for what they _believe_ is feasible. I've
seen users encounter an obvious bug, and work around it by hand, and turn
around and ask for something completely different, like an alternative
workaround. (Just add a macro system so I can record this sequence of 7 steps
to work around this weird thing...) They literally don't think to ask "Fix
this bug".

I wonder if that's what's happening here. As an occasional Firefox user, I
know that keyboard shortcuts have been broken since the Bush administration,
and the codebase is far too complex for me to work on even the simplest
features (I've tried). I can absolutely see a user thinking "If they can't do
what we want, at least they could do it faster". That feels like a change
that's feasible in a way that "Fix the massive complexity problem" or even
"Fix keyboard shortcuts (which are apparently massively complex)" do not.

Firefox itself was created by a couple programmers chatting late at night in a
Denny's. They made a far better browser than the Mozilla organization of the
day could. It's an important organization and it's impressive they can
regularly ship useful free software, but user interfaces have never been a
strong point for open source, in the way that compilers and runtimes and
databases are. Tweak away, but I don't hold much hope for the situation to
improve. The next great open-source browser is going to come from 2 or 3
people chatting in a Denny's, not Mozilla with N-week releases, for any value
of N.

~~~
maxerickson
What's a concrete example of a broken shortcut?

The shortcuts I use work fine, so I don't understand the complaint.

~~~
boring_twenties
Some shortcuts I use -- like Alt-$NUMBER to jump to a specific tab -- are
frequently overridden by websites, which I view as a browser breakage because
this should simply not be allowed.

~~~
roca
Obviously this is a tough one since most users don't know those shortcuts
exist and will get upset if those shortcuts stop working in a Web site.

