Live data from Hacker News

Firefox moving to 4 week releases

hacks.mozilla.org

21–30 of 195 posts

Re: Firefox moving to 4 week releases

#21

Earlier quoted context omitted.

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

> 28 extensions Yeah, you should probably hold off on the bug report.

In fairness, it's still a bug, just way over the cost/benefit threshold to bisect:|

Re: Firefox moving to 4 week releases

#22
post #13
post #3

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

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.

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

Re: Firefox moving to 4 week releases

#23
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…

There may have been a late night Denny's involved, but the rendering engine inside the original Phoenix/Firefox came out of the existing Netscape codebase. And that had thousands and thousands and thousands of person hours invested in it, by a largish engineering org, before Firefox saw the light of day.

Re: Firefox moving to 4 week releases

#24
post #16
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…

What's broken with keyboard shortcuts?

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

Re: Firefox moving to 4 week releases

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

Re: Firefox moving to 4 week releases

#26

Earlier quoted context omitted.

Have you filed a bug about the resource leaks?

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

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

Re: Firefox moving to 4 week releases

#27
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.

If releases are painful, then something is wrong with your development cycle and deployment process. If you spend the effort to make it painless, then it makes no difference whether releases are 6 weeks or 4 weeks.

Of course, you need an extensive battery of unit tests and integration tests, and lots of user testing in beta. But actually if you're only deploying smaller self-contained changes then there's less moving parts at any given time. You'll have stronger guarantees of less interactions.

Re: Firefox moving to 4 week releases

#28
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.

A faster release cycle done right mean fewer features are added per release -- you are releasing 4 weeks of engineering work instead of 8 weeks or whatever. This can make bugs less likely if done right. It also makes it a lot easier to react quickly to bugs that do get released, and if you have to roll back you are rolling back fewer new features.

Re: Firefox moving to 4 week releases

#29
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.

You can always use the Firefox Extended Support Release, which is updated far less frequently and is (hypothetically) more stable:

https://support.mozilla.org/en-US/kb/choosing-firefox-update...

Re: Firefox moving to 4 week releases

#30
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.

A faster release cycle done right mean fewer features are added per release -- you are releasing 4 weeks of engineering work instead of 8 weeks or whatever. This can make bugs less likely if done right. It also makes it a lot easier to react quickly to bugs that do get released, and if you have to roll back you are rolling back fewer new features.

As you've said: done right.

Done poorly, or even in a mediocre fashion, and we've got more half-baked features and insufficiently-tested changes.

Now, which scenario is more likely?

Post reply on HN