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

Remember back then when enterprises certified their entire install base against FF3, but then FF4 came out & they needed to redo all the enterprise certification bullshit.

zach_galifianakis_laugh.mp4

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.

Totally. I think of this as the "next bus" effect. If you see your bus pulling up, do you run for it? If the next bus is in 5 minutes, no. If it's once a week, hell yes.