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

71–80 of 195 posts

Re: Firefox moving to 4 week releases

#71

Post by kingofpandora »

aquabeagle wrote: post #62
fluffything wrote: post #57

Earlier quoted context omitted.

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…

Mozilla only provides binaries for Linux 32-bit, Linux 64-bit, macOS, win32, and win64: 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-…

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

Re: Firefox moving to 4 week releases

#72

Post by bri3d »

lizzard wrote: post #63
bri3d wrote: post #37

Earlier quoted context omitted.

> Surely not from the users. I'd love for the recent changes to rendering which fix long standing performance issues on OSX to hit release as soon as possible. https://twitter.com/whimboo/status/1168437524357898240 . Many users are running nightly right now to take up these changes because they are so valuable. As a user, I'm requesting Firefox take features to market sooner :) > Poor guys. At least the process “guar…

I actually took those changes in 70, so they should make it to the release version at the end of October. If you can, please try using 70 Beta and see how the power use improves! https://bugzilla.mozilla.org/show_bug.cgi?id=1574538

Thank you so much! The nightlies have been good and I will try the beta.

Re: Firefox moving to 4 week releases

#73

Post by jonathankoren »

ksec wrote: post #70

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

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.

Re: Firefox moving to 4 week releases

#74

Post by cpeterso »

I_AM_A_SMURF wrote: post #52
esfandia wrote: post #34

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.

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

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

Re: Firefox moving to 4 week releases

#75

Post by ratmice »

bengoodger wrote: post #66
Ididntdothis wrote: post #54

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.

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…

I've been in both situations of missing the 12 month boat, and rushing to get something in before the boat leaves port, and it's terrible.

that said I think 4 weeks is a real short release cycle. 3 months, so 4 releases a year -- one for each season. Would seem to strike a better balance.

Re: Firefox moving to 4 week releases

#76

Post by jasonlotito »

ksec wrote: post #70

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

Yeah, you are missing something. I'll help you though and explain. =)

So, let's say a feature takes 7 weeks to properly build and test. You start on week 1.

Now, after 6 weeks, a release goes out. A week later, your feature is done. You now have to wait 5 weeks before your release goes out. So, you merge your feature and move on to your next feature. 5 weeks later, your features is released.

So, to release a feature that takes 7 weeks, you had to wait 12 weeks.

Now, with a 4 week release schedule, you only have to wait 1 week.

This is a bit simple, but it really works this way. Now, here is the other end of the spectrum.

Let's say the release schedule is once every 12 weeks. (Under the idea that quicker is worse and slower is better). Now, let's say at week 6, you start your 7 week feature. It will get done on week 13, and have to wait 11 weeks to get released. That's a long time! So what happens? Well, what tends to happen is people push to get it done in 6 weeks rather than 7. That means skipping steps, working longer hours, and cutting corners. Why? Because they don't want to finish with something and have to wait 11 weeks for it to get released. They want to get it out there.

However, if you know that the longest you have to wait is 4 weeks, that's a lot more palatable.

> And features requires time to think, design, bake, tested in real world and refine,

Having more frequent releases doesn't change that.

> having a few more releases in between those process doesn't make the features come out any quicker.

tl;dr: They don't make finishing the feature faster. But they do allow finished features to get released faster. =)

Re: Firefox moving to 4 week releases

#77

Post by cpeterso »

kenhwang wrote: post #49
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 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.

Re: Firefox moving to 4 week releases

#78

Post by cpeterso »

Zenst wrote: post #55
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?

Good point, but factor in build/release, then deployment. We all know what some companies are like in their desktop real estate rollouts - if you have too frequent updates, you end up with greater disparity in releases with a template support of - oh that's not the latest, pls try again. Then feedback, if you rollout release too frequently you also can be several releases in and get feedback of some bug in a release…

> kudos for not just picking a day a month and doing monthly updates like most, that tends to seem more arbitrary unlike 4 weeks

Planning feature development and rollout is more difficult if you always have to refer to a calendar to find future release dates. I would prefer to be able to say a feature can land in Firefox Nightly in January, ship to Firefox Beta on February 1, and Release channel users on March 1.

Mozilla has a long wiki page of past and future release dates:

https://wiki.mozilla.org/RapidRelease/Calendar

Re: Firefox moving to 4 week releases

#79

Post by xg15 »

nwah1 wrote: post #42
WoodenChair wrote: post #38

Earlier quoted context omitted.

You're addressing the pain for the developer but not the pain for the user and society more largely. The user (who may be on a slow internet connection) has to deal with the bandwidth of the more frequent downloads. Society has to deal with additional network congestion costs and electricity usage.

True, but by using binary deltas you can minimize that cost. And failure to upgrade may mean running more inefficient algorithms, wasting more processor cycles, or transferring more data in general. For instance, if you are on a browser that doesn't support Brotli compression then you'll miss out on the dramatic compression improvements provided by that algorithm.

It also means more effort for people who have to validate the changes downstream for potential problems - e.g. extension developers or package maintainers.

Re: Firefox moving to 4 week releases

#80

Post by masklinn »

ratmice wrote: post #75
bengoodger wrote: post #66

Earlier quoted context omitted.

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…

I've been in both situations of missing the 12 month boat, and rushing to get something in before the boat leaves port, and it's terrible. that said I think 4 weeks is a real short release cycle. 3 months, so 4 releases a year -- one for each season. Would seem to strike a better balance.

Firefox has been on a 6 weeks cycle for a few years now, clearly they found that short release suited them, and that it was if anything too long. Different strokes and all that.
Post reply on HN