18 ms·

Firefox moving to 4 week releases

332 points by rebelwebmaster 7y ago

chaosmachine 7y ago
According to my calculations, this means Firefox 100 will be released on 2022-03-08.
- discreditable 7y ago
  I bet they will switch to date-based releases long before then.
  - rovr138 7y ago
    I kind of want to see Firefox 100
    - mroche 7y ago
      Firefox C
- cozzyd 7y ago
  And in 2702 we will see Firefox 9001. A long time to wait for a silly joke :(
- zepearl 7y ago
  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 7y ago
    Semantic versioning is useful. Unfortunately the marketers have taken over and there's a numbers race going on.
    - sroussey 7y ago
      Semantic versioning is useful for libraries. Let useful for consumer apps. 2019-10 says more than 76.0.0
      - masklinn 7y ago
        > 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 7y ago
        2014-04 is absolutely actionable for a browser.
        MaulingMonkey 7y ago
        2014-04 is actionable for a lot of stuff - "unpatched" or "unmaintained"...
      - lenkite 7y ago
        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
        diegoperini 7y ago
        But if a website breaks, you can get more idea about why it happened by comparing your current browser's calendar version to the latest update. For example, you will know you are behind x years of updates. With semantic versioning, you don't know how old you have not been updating your installation. Since there are more websites than extensions, the utilitarian approach would be to choose 2019-10 over 76.0.0.
  - sarah180 7y ago
    The reality is that you must read the release notes for this to be a strategy that can even remotely minimize your risk. On one side, relatively minor upgrades can have huge impacts for some use cases. Some changes are riskier than others, but SemVer and major/minor distinctions are not reliable signals for anything critical. More important though, if you're skipping browser updates at all, you need to be tracking the security implications of every patch you skip. Otherwise you're increasing your risk by an order of magnitude more than you'd reduce it by deciding a change might be too buggy based on a numbering scheme.
  - d00bianista 7y ago
    Aside from versioning being clear about how big the change is, Windows Installer has this [0-255].[0-255].[0-65535] limit that I hope people do not learn about in the hard ways. It's not so fun to work around because Windows Installer tries to be smart about things, as opposed to the others that take a more robust approach. https://docs.microsoft.com/en-us/windows/win32/msi/productversion https://docs.microsoft.com/en-us/windows/win32/msi/productve...
    - anticensor 7y ago
      Firefox has a custom installer.
- paulddraper 7y ago
  Only 16 years short of 2038.
- conradfr 7y ago
  To be honest I have no idea what Firefox version I use right now, just that it's the latest.
lvh 7y ago
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 7y ago
  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 7y ago
    Yeah, I especially like that Mozilla's own pages will tell me my browser is out of date when running ESR:)
- ShakataGaNai 7y ago
  It's Duo that has the "Software Update Notification" feature ( https://guide.duo.com/software-update https://guide.duo.com/software-update ). If more vendors go the direction of faster updates, that feature on Duo (and I'm sure others) will need to be tweaked heavily.
  - lvh 7y ago
    I mean, it’s pretty broken right now, so maybe not?
acqq 7y ago
> In recent quarters, we’ve had many requests to take features to market sooner. Surely not from the users. > Feature teams are increasingly working in sprints that align better with shorter release cycles. Poor guys. At least the process “guarantees” long term quality as the result. > Shorter release cycles provide greater flexibility to support product planning and priority changes due to business or market requirements. Translation: marketing managers want to change their minds faster than up to now. I’d prefer more stable, less CPU and battery hungry browser than one that shovels to my desktop the newly decided features from the marketing as soon as possible. But it’s just me.
- tasty_freeze 7y ago
  Your first comment implies you speak for all users; certainly you don't. Your second comment is antagonistically sarcastic. Your third comment is easy cynicism. As a counterpoint, Firefox does put a lot of effort into stability, reducing CPU power (read the recent change on OSX in that regard). You seem to be suggesting a shorter release cycle will prevent them from continuing that work.
  - acqq 7y ago
    > Your first comment implies It doesn't. > certainly you don't. I don't. I speak just for all the users that don't benefit from the more frequent release cycle. Note that the more frequent release cycle doesn't mean that any development will take less (especially absolute) time. It can even take more, as more frequent release cycles mean that administrative work related to every release increases. > You seem to be suggesting a shorter release cycle will prevent them from continuing that work. No. Again you construct what I haven't said, because you don't have valid arguments against what I've actually said. I'm claiming that the total work by both the developers inside of Mozilla and by all the users who have to respond to the event of the new release increases with this management decision. And I quote the argument of the management, written in the release, which I consider to be weak compared to the said costs: "Shorter release cycles provide greater flexibility to support product planning and priority changes due to business or market requirements"
- 7y ago
ThoughtfulToad 7y ago
That's a lot of releases!
Mathnerd314 7y ago
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 7y ago
  Have you filed a bug about the resource leaks?
  - Mathnerd314 7y ago
    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.
    - misterdoubt 7y ago
      > 28 extensions Yeah, you should probably hold off on the bug report.
      - yjftsjthsd-h 7y ago
        In fairness, it's still a bug, just way over the cost/benefit threshold to bisect:|
    - gorhill 7y ago
      > 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".
ken 7y ago
> 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.
- ChrisSD 7y ago
  What's broken with keyboard shortcuts?
  - michaelmrose 7y ago
    Not being able to configure them would be one thing. The lack of a shortcut to open reader mode for years another.
JohnFen 7y ago
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.
- nwah1 7y ago
  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.
  - WoodenChair 7y ago
    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.
    - nwah1 7y ago
      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.
      - xg15 7y ago
        It also means more effort for people who have to validate the changes downstream for potential problems - e.g. extension developers or package maintainers.
esfandia 7y ago
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.
- vvillena 7y ago
  No you don't. You had automated updates before, and you'll have automated updates now. Same with Chrome.
  - boring_twenties 7y ago
    That is already addressed in the parent comment, "deal with a more frequent risk of getting an update I don't like"
    - Ajedi32 7y ago
      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.
      - acqq 7y ago
        Whoever spends some fixed amount of time evaluating the release will now spend more than 50% time than before. I’m one of those. If I’m only one of 200 (as in, 199 don't care) and if Firefox has 200 million users, Firefox will waste millions of hours of user’s time per each additional release.
        Ajedi32 7y ago
        Sounds like Firefox ESR is for you then.
      - boring_twenties 7y ago
floatboth 7y ago
Should've kept the major at 69 and started incrementing the minor only, forever. The browser must be nice! :D
- gnulinux 7y ago
  Do you mind not doing this here? This is not reddit. We're trying to have a valuable discussion here.
lucb1e 7y ago
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?
- kelnos 7y ago
  I think it's more a matter of discipline than anything else. It's easy to get lost in the weeds with a ton of things waiting to be merged, and over and over saying "just one more PR to merge and then I'll release", and then it's a year later and you still haven't released. Getting features out to people faster means shorter feedback cycles. Regarding versioning, most applications don't use semantic versioning; that's mainly for libraries. Not sure what "backwards incompatible" would mean for a browser, anyway.
  - Karunamon 7y ago
    Addons, plug-ins, CSS and HTML directives, etc.
    - dikei 7y ago
      I would argue that you should do features detection rather than depending on version number, as much as possible.
- kenhwang 7y ago
  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.
  - jaas 7y ago
    "probably had bad memories" Speaking as someone who was at Mozilla at that time, you can change "probably had" to "definitely has". In hindsight I'd go ahead and call it a disaster. The X weeks release cadence solves so many problems.
RippleMeHarder 7y ago
It's important to ensure that the parasitic cryptominer that will sooner or later get bundled with it remains evergreen.
Ididntdothis 7y ago
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.
- lizzard 7y ago
  Firefox ESR exists for exactly this reason. It gets periodic security fixes but not much else and you can stay on the same major version for a year or so. https://www.mozilla.org/firefox/enterprise/ https://www.mozilla.org/firefox/enterprise/
  - flukus 7y ago
    > Extended Support Release (ESR): receives major updates on average every 42 weeks It feels like they're just taking the piss when the life cycle of an extended support release is just 42 weeks. Still a step in the right direction though.
    - roca 7y ago
      The lifetime of each ESR is one year, there's an intentional 10 week overlap.
- bengoodger 7y ago
  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.
  - ratmice 7y ago
ksec 7y ago
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 7y ago
  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.
- jasonlotito 7y ago
  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. =)
iagooar 7y ago
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.
- saghm 7y ago
  Absolutely nobody? I update all the packages on my Linux machines (personal ones, not servers) at least daily. I'm happy to get any changes as soon as they're released. Obviously I'm likely in the minority here, but is it really that inconceivable that a decent number of people might be fine with updating their browser once a month? It's a pretty quick process, and for the average user who isn't using many extensions (if any), things don't really break when it updates.
- yes-except-no 7y ago
  >Nobody wants to update their browser this frequently hi, I run nightly and get prompts that my browser has updated daily. I simply ignore them, and it'll be patched by the time I start up firefox the next time, because it updates in the background. And so does regular firefox. You don't see Chrome updating, and yet they're pushing out more releases than firefox ever did.
- pingyong 7y ago
  >Nobody wants to update their browser this frequently Uhh really? Pretty sure "most people" don't even notice when their browser updates.
  - Grue3 7y ago
    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 7y ago
      Clicking close and then clicking restore session takes 5 seconds or so. Why are you "almost never" restarting?
ShakataGaNai 7y ago
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 7y ago
  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.
tanchoux 7y ago
4 week releases will create 13 versions by year. We will use Firefox 211 in 2030 (if they don't change rules).
deleted 7y ago
[deleted]
efiecho 7y ago
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 7y ago
  You're not obliged to update every four weeks. Why not continue updating as often as you currently do?
  - efiecho 7y ago
    There will usually be many security fixes with each new release, so I have no choice.
    - untog 7y ago
      So surely more frequent releases is a good thing: you're getting security updates quicker.
- pranith 7y ago
  The long term extended support release might be a suitable option for you in that case... https://www.mozilla.org/en-US/firefox/enterprise/ https://www.mozilla.org/en-US/firefox/enterprise/
dungdev 7y ago
Hmmmm. I don’t really like these quick release cycles
ninguem2 7y ago
Why do I seem to get a firefox update on ubuntu on a daily basis?
- swebs 7y ago
  Security updates need to be released ASAP.
sekoidd 7y ago
should i use firefox or chrome?
foamclutching 7y ago
Good. Let's just hope that Firefox won't become like PUBG. Quick-release, bad optimization.
KuhlMensch 7y ago
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!

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

discreditable 7y ago
I bet they will switch to date-based releases long before then.
- rovr138 7y ago
  I kind of want to see Firefox 100
  - mroche 7y ago
    Firefox C
cozzyd 7y ago
And in 2702 we will see Firefox 9001. A long time to wait for a silly joke :(
zepearl 7y ago
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 7y ago
  Semantic versioning is useful. Unfortunately the marketers have taken over and there's a numbers race going on.
  - sroussey 7y ago
    Semantic versioning is useful for libraries. Let useful for consumer apps. 2019-10 says more than 76.0.0
    - masklinn 7y ago
      > 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 7y ago
        2014-04 is absolutely actionable for a browser.
        MaulingMonkey 7y ago
        2014-04 is actionable for a lot of stuff - "unpatched" or "unmaintained"...
    - lenkite 7y ago
      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
      - diegoperini 7y ago
        But if a website breaks, you can get more idea about why it happened by comparing your current browser's calendar version to the latest update. For example, you will know you are behind x years of updates. With semantic versioning, you don't know how old you have not been updating your installation. Since there are more websites than extensions, the utilitarian approach would be to choose 2019-10 over 76.0.0.
- sarah180 7y ago
  The reality is that you must read the release notes for this to be a strategy that can even remotely minimize your risk. On one side, relatively minor upgrades can have huge impacts for some use cases. Some changes are riskier than others, but SemVer and major/minor distinctions are not reliable signals for anything critical. More important though, if you're skipping browser updates at all, you need to be tracking the security implications of every patch you skip. Otherwise you're increasing your risk by an order of magnitude more than you'd reduce it by deciding a change might be too buggy based on a numbering scheme.
- d00bianista 7y ago
  Aside from versioning being clear about how big the change is, Windows Installer has this [0-255].[0-255].[0-65535] limit that I hope people do not learn about in the hard ways. It's not so fun to work around because Windows Installer tries to be smart about things, as opposed to the others that take a more robust approach. https://docs.microsoft.com/en-us/windows/win32/msi/productversion https://docs.microsoft.com/en-us/windows/win32/msi/productve...
  - anticensor 7y ago
    Firefox has a custom installer.
paulddraper 7y ago
Only 16 years short of 2038.
conradfr 7y ago
To be honest I have no idea what Firefox version I use right now, just that it's the latest.

lvh 7y ago

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 7y ago
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 7y ago
  Yeah, I especially like that Mozilla's own pages will tell me my browser is out of date when running ESR:)
ShakataGaNai 7y ago
It's Duo that has the "Software Update Notification" feature ( https://guide.duo.com/software-update https://guide.duo.com/software-update ). If more vendors go the direction of faster updates, that feature on Duo (and I'm sure others) will need to be tweaked heavily.
- lvh 7y ago
  I mean, it’s pretty broken right now, so maybe not?

acqq 7y ago

> In recent quarters, we’ve had many requests to take features to market sooner. Surely not from the users. > Feature teams are increasingly working in sprints that align better with shorter release cycles. Poor guys. At least the process “guarantees” long term quality as the result. > Shorter release cycles provide greater flexibility to support product planning and priority changes due to business or market requirements. Translation: marketing managers want to change their minds faster than up to now. I’d prefer more stable, less CPU and battery hungry browser than one that shovels to my desktop the newly decided features from the marketing as soon as possible. But it’s just me.

tasty_freeze 7y ago
Your first comment implies you speak for all users; certainly you don't. Your second comment is antagonistically sarcastic. Your third comment is easy cynicism. As a counterpoint, Firefox does put a lot of effort into stability, reducing CPU power (read the recent change on OSX in that regard). You seem to be suggesting a shorter release cycle will prevent them from continuing that work.
- acqq 7y ago
  > Your first comment implies It doesn't. > certainly you don't. I don't. I speak just for all the users that don't benefit from the more frequent release cycle. Note that the more frequent release cycle doesn't mean that any development will take less (especially absolute) time. It can even take more, as more frequent release cycles mean that administrative work related to every release increases. > You seem to be suggesting a shorter release cycle will prevent them from continuing that work. No. Again you construct what I haven't said, because you don't have valid arguments against what I've actually said. I'm claiming that the total work by both the developers inside of Mozilla and by all the users who have to respond to the event of the new release increases with this management decision. And I quote the argument of the management, written in the release, which I consider to be weak compared to the said costs: "Shorter release cycles provide greater flexibility to support product planning and priority changes due to business or market requirements"
7y ago

ThoughtfulToad 7y ago

That's a lot of releases!

Mathnerd314 7y ago

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 7y ago
Have you filed a bug about the resource leaks?
- Mathnerd314 7y ago
  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.
  - misterdoubt 7y ago
    > 28 extensions Yeah, you should probably hold off on the bug report.
    - yjftsjthsd-h 7y ago
      In fairness, it's still a bug, just way over the cost/benefit threshold to bisect:|
  - gorhill 7y ago
    > 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".

ken 7y ago

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

ChrisSD 7y ago
What's broken with keyboard shortcuts?
- michaelmrose 7y ago
  Not being able to configure them would be one thing. The lack of a shortcut to open reader mode for years another.

JohnFen 7y ago

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.

nwah1 7y ago
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.
- WoodenChair 7y ago
  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.
  - nwah1 7y ago
    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.
    - xg15 7y ago
      It also means more effort for people who have to validate the changes downstream for potential problems - e.g. extension developers or package maintainers.

esfandia 7y ago

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.

vvillena 7y ago
No you don't. You had automated updates before, and you'll have automated updates now. Same with Chrome.
- boring_twenties 7y ago
  That is already addressed in the parent comment, "deal with a more frequent risk of getting an update I don't like"
  - Ajedi32 7y ago
    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.
    - acqq 7y ago
      Whoever spends some fixed amount of time evaluating the release will now spend more than 50% time than before. I’m one of those. If I’m only one of 200 (as in, 199 don't care) and if Firefox has 200 million users, Firefox will waste millions of hours of user’s time per each additional release.
      - Ajedi32 7y ago
        Sounds like Firefox ESR is for you then.
    - boring_twenties 7y ago

floatboth 7y ago

Should've kept the major at 69 and started incrementing the minor only, forever. The browser must be nice! :D

gnulinux 7y ago
Do you mind not doing this here? This is not reddit. We're trying to have a valuable discussion here.

lucb1e 7y ago

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?

kelnos 7y ago
I think it's more a matter of discipline than anything else. It's easy to get lost in the weeds with a ton of things waiting to be merged, and over and over saying "just one more PR to merge and then I'll release", and then it's a year later and you still haven't released. Getting features out to people faster means shorter feedback cycles. Regarding versioning, most applications don't use semantic versioning; that's mainly for libraries. Not sure what "backwards incompatible" would mean for a browser, anyway.
- Karunamon 7y ago
  Addons, plug-ins, CSS and HTML directives, etc.
  - dikei 7y ago
    I would argue that you should do features detection rather than depending on version number, as much as possible.
kenhwang 7y ago
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.
- jaas 7y ago
  "probably had bad memories" Speaking as someone who was at Mozilla at that time, you can change "probably had" to "definitely has". In hindsight I'd go ahead and call it a disaster. The X weeks release cadence solves so many problems.

RippleMeHarder 7y ago

It's important to ensure that the parasitic cryptominer that will sooner or later get bundled with it remains evergreen.

Ididntdothis 7y ago

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.

lizzard 7y ago
Firefox ESR exists for exactly this reason. It gets periodic security fixes but not much else and you can stay on the same major version for a year or so. https://www.mozilla.org/firefox/enterprise/ https://www.mozilla.org/firefox/enterprise/
- flukus 7y ago
  > Extended Support Release (ESR): receives major updates on average every 42 weeks It feels like they're just taking the piss when the life cycle of an extended support release is just 42 weeks. Still a step in the right direction though.
  - roca 7y ago
    The lifetime of each ESR is one year, there's an intentional 10 week overlap.
bengoodger 7y ago
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.
- ratmice 7y ago

ksec 7y ago

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 7y ago
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.
jasonlotito 7y ago
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. =)

iagooar 7y ago

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.

saghm 7y ago
Absolutely nobody? I update all the packages on my Linux machines (personal ones, not servers) at least daily. I'm happy to get any changes as soon as they're released. Obviously I'm likely in the minority here, but is it really that inconceivable that a decent number of people might be fine with updating their browser once a month? It's a pretty quick process, and for the average user who isn't using many extensions (if any), things don't really break when it updates.
yes-except-no 7y ago
>Nobody wants to update their browser this frequently hi, I run nightly and get prompts that my browser has updated daily. I simply ignore them, and it'll be patched by the time I start up firefox the next time, because it updates in the background. And so does regular firefox. You don't see Chrome updating, and yet they're pushing out more releases than firefox ever did.
pingyong 7y ago
>Nobody wants to update their browser this frequently Uhh really? Pretty sure "most people" don't even notice when their browser updates.
- Grue3 7y ago
  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 7y ago
    Clicking close and then clicking restore session takes 5 seconds or so. Why are you "almost never" restarting?

ShakataGaNai 7y ago

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 7y ago
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.

tanchoux 7y ago

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

deleted 7y ago

[deleted]

efiecho 7y ago

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 7y ago
You're not obliged to update every four weeks. Why not continue updating as often as you currently do?
- efiecho 7y ago
  There will usually be many security fixes with each new release, so I have no choice.
  - untog 7y ago
    So surely more frequent releases is a good thing: you're getting security updates quicker.
pranith 7y ago
The long term extended support release might be a suitable option for you in that case... https://www.mozilla.org/en-US/firefox/enterprise/ https://www.mozilla.org/en-US/firefox/enterprise/

dungdev 7y ago

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

ninguem2 7y ago

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

swebs 7y ago
Security updates need to be released ASAP.

sekoidd 7y ago

should i use firefox or chrome?

foamclutching 7y ago

Good. Let's just hope that Firefox won't become like PUBG. Quick-release, bad optimization.

KuhlMensch 7y ago

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!