Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Firefox moving to 4 week releases

hacks.mozilla.org

Post reply on HN
Print view View original

91–100 of 195 posts

Re: Firefox moving to 4 week releases

#91

Post by boring_twenties »

Ajedi32 wrote: post #45
boring_twenties wrote: post #39

Earlier quoted context omitted.

That is already addressed in the parent comment, "deal with a more frequent risk of getting an update I don't like"

This isn't going to significantly increase the speed at which new features are developed, just the speed at which they're released. The overall risk of you encountering a new feature you don't like won't be higher.

It's not necessarily the number of features but the process of preparing oneself for changes likely to be surprising, unpleasant, require workarounds or length research as to workarounds, etc.

Even if it's just a matter of reading the release notes, having to do that twice as often is a non-zero burden.

Of course there is Firefox ESR but I seem to remember Mozilla's website basically explicitly recommending against it with language along the lines of "This is only for people whose corporate policies require it, don't install it unless you have no other choice."

Re: Firefox moving to 4 week releases

#92

Post by lenkite »

sroussey wrote: post #50
Someone1234 wrote: post #40

Earlier quoted context omitted.

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

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

Well, I don't get an idea if my extension would break changing from version 2019-10 -> 2019-11 without reading the release notes.

I would know it there is a big chance of breakage if I moved from 76.0.0 -> v77.0.0 and I am reasonably certain it won't break if I moved from 76.0.0 -> 76.0.1

Re: Firefox moving to 4 week releases

#93

Post by quickthrower2 »

ken wrote: post #15

> 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 st…

> They made a far better browser than the Mozilla organization of the day could

I'm guessing this is not the case, because the demands and requirements of browsers would have increased massively since then in terms of the breadth of the developer APIs and security issues that need to be dealt with, plus an every increasing demand on speed and having the largest company in the world with effectively unlimited cash, the best minds and some sharp practices as your competitor.

Re: Firefox moving to 4 week releases

#94

Post by zbraniecki »

cpeterso wrote: post #77
kenhwang wrote: post #49

Earlier quoted context omitted.

Firefox probably had bad memories of when they "released when it's ready" during the FF3 -> FF4 days where a couple of features held back everything. With fix released cycles, they have more of a motivator to cut off things that aren't ready yet so that the things that are can go out.

With shorter release cycles, there's also less pressure to ship half-baked features. If you know the next release is just four weeks away, then slipping a feature one release is rarely a huge deal. But if the next release is one quarter or one year away, teams rush to ship now and fix bugs in production later. Overall product quality will take a hit at every release.

Another thing that I observed in our culture since we switched is that it is easier to coordinate cross-team efforts - if I know X will be done in Fx70, I can plan my work on top of it for 71.

Such logic is commonly performed without releases until you start depending on multiple features in multiple places. Then it saves you.

The same "alignment" works also much better between engineering and non-engineering teams. Once we collect the focus areas and major features planned for release X, security, performance, accessibility, localization, platform integration, UI, UX, design, legal and marketing teams can prioritize their work to aid them.

Having no release cycle, or long release cycle, dilutes this effort and reduces visibility.

There is, in my opinion, somewhere, a threshold beyond which the release cycle burden outweighs the benefits and/or where the cycle is to short for teams to usefully react, but I don't think we hit it so far.

Re: Firefox moving to 4 week releases

#95

Post by LinuxBender »

fluffything wrote: post #57
lucb1e wrote: post #46

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?

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 eve…

Not to mention, different builds per language for each OS. [1] This has never really made sense to me, but I'm sure there must be a good reason.

[1] - https://ftp.mozilla.org/pub/firefox/releases/68.1.0esr/linux...

Re: Firefox moving to 4 week releases

#96

Post by zbraniecki »

ken wrote: post #15

> 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 st…

> Firefox itself was created by a couple programmers chatting late at night in a Denny's.

You're presenting a very naive and romanticized version of the story.

source: I've been involved in Phoenix since 0.2.

Re: Firefox moving to 4 week releases

#97

Post by wott »

Someone1234 wrote: post #40
zepearl wrote: post #32

Earlier quoted context omitted.

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. . . ) 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 :(

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

And this supposed marketing advantage only lasted for the first handful of releases, when numbers where under or around 10. Now numbers are so big that they have become totally insignificant. 57? 63? 98? who cares any more?

Furthermore, as another comment said, it is impossible to remember on which release they started breaking this or that, since there is no more major version number change, which is usually handy to indicate backward-incompatible changes.

Re: Firefox moving to 4 week releases

#98

Post by omaranto »

i_cant_speel wrote: post #31
michaelmrose wrote: post #24

Earlier quoted context omitted.

Not being able to configure them would be one thing. The lack of a shortcut to open reader mode for years another.

Cmd + alt + r

I don't know what cmd means (I'm kidding, I have seen Apple computers even if I've never used one), but you can find out what the keyboard shortcut is on your own copy of Firefox by hovering the mouse over the Reader mode icon. On my Firefox it says "Ctrl + Alt + R".

Re: Firefox moving to 4 week releases

#99

Post by jillesvangurp »

JohnFen wrote: post #25

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.

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.

Re: Firefox moving to 4 week releases

#100

Post by aylmao »

lucb1e wrote: post #46

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?

> Why release on a schedule at all?

I feel like it might help with motivation. It's easy to push things "to tomorrow" if you don't have a hard cap on how many tomorrows are available before the feature is supposed to go out.

> 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?

It's kind of like forming a habit. Having a set schedule could in theory delay quick features, but it will also keep the motivation going for time-consuming features.

> And why does this have to increment the major version, since when is every single update backwards incompatible?

I actually really like this personally. Encoding compatibility in a version number is, IMO, useless— it's sometimes just hard to know if your changes will break something or not, so there's a wealth of minor versions out there that break things anyway.

Just using a single number just makes everything simpler. Detecting breaking changes should be done with systems (tests, static analysis, etc) and not by trusting a number some developer came up with.

Post reply on HN