Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
(For real, though, I still think incrementing your major version number every six weeks without consideration of whether your changes are actually major is bad. I can never tell what the current version of Firefox or Chrome or Edge is, nor can I tell when the last time they made major changes was. But I can with Safari, because their version numbers make sense.)
That’s because it’s less about “versions” and more about “releases”. It just tracks releases with each release usually being a modest incremental update on the previous. Each one is numbered incrementally. 1,2,3…95.

What does the other style of major.minor.build really tell you that is so much more useful? Did that feature or fix come out in 14 or was it 14.2 or was it 14.2.1?
 
When wil Firefox be able to use my iCloud bookmarks. The is literally the main thing from having me switch to it on my personal machine. On my work machine I use it all the time. As a web developer I prefer the Firefox debuting tools and occasionally I find issues that the people using Chrome don't see, although that is getting less and less.
I prefer to keep my work bookmarks and my personal bookmarks separate.
 
That’s because it’s less about “versions” and more about “releases”.

I really don't know what this is supposed to mean. A "release" is just the process of creating a version.

It just tracks releases with each release usually being a modest incremental update on the previous. Each one is numbered incrementally. 1,2,3…95.

What does the other style of major.minor.build really tell you that is so much more useful? Did that feature or fix come out in 14 or was it 14.2 or was it 14.2.1?

Features — other than very minor ones — aren't supposed to come out in an x.y.z release.

I know when iOS 15, or Windows 11, or whatever else gets released that there will be multiple major features. Therefore, I might be interested in taking a look at those releases. iOS 15.1 and Windows 11 22H1 will be less interesting, by comparison. iOS 15.1.2 and Windows Random Monthly Round Of Security Patches is mostly nothing to write home about, unless there's a fix for a bug that has affected me. I don't know when Firefox 95, 96, or 97 come out whether there is anything of note, at all.
 
Features — other than very minor ones — aren't supposed to come out in an x.y.z release.

That's what happens when a versioning scheme like e.g. Semantic Versioning is in use, but Firefox does not use such scheme.

Firefox's releases are split in "channels", with the default channel having a new major release every 4 weeks, meaning that new features and potential backward incompatibilities can happen with that cadence.

For those who want or need a less frequent cadence, there is the Extended Support Release channel. Those who want an even faster cadence can opt for the Beta or even Nightly channel (typically developers who want to test new features earlier).
 
That's what happens when a versioning scheme like e.g. Semantic Versioning is in use, but Firefox does not use such scheme.

That's primarily for libraries. But yes, um, Firefox doesn't do that. Which is what I'm criticizing??


For those who want or need a less frequent cadence, there is the Extended Support Release channel.

That slows the cadence, sure, but it's still a cadence. There doesn't appear to be any editor who decides "these features make for a useful release".
 
That's primarily for libraries. But yes, um, Firefox doesn't do that. Which is what I'm criticizing??

That slows the cadence, sure, but it's still a cadence. There doesn't appear to be any editor who decides "these features make for a useful release".

That's because the process is explicitly meant to avoid that type of thinking.

With the older style, a version number change was a rare event that signified major change. As a result, releases often were pushed back by months as programmers worked to include and debug their new features. With the rapid-release approach, new versions of Firefox ship quarterly with whatever new features are done. The consequences to missing the release train are lower, since another train will come around again soon.

Note that the cadence was increased later on as the new release plan proved successful.
 
  • Like
Reactions: Tagbert
I know — and I think it's a bad decision, and I'm happy Apple (so far) hasn't gone down the same route.

I'm not sure why you keep pointing out that they made that decision. Indeed, they did, and I disagree with it.

OK, that's fair, but it was not so clear to me that you were aware of the reasoning behind that decision.

Apple has currently a somewhat compromise approach with the Safari Technology Preview, but I think it's basically the only remaining "big browser" which doesn't use a rapid-release approach for their stable version.

It would not surprise me if they also move more in a rapid-release process in the future.
 
Apple has currently a somewhat compromise approach with the Safari Technology Preview,

Yeah, I suppose. But the mainline Safari just has the traditional versioning model, and Safari TP just gets merged into it (and even TP will still give the regular version: "Release 136 (Safari 15.4, WebKit 17613.1.9.2)").

but I think it's basically the only remaining "big browser" which doesn't use a rapid-release approach for their stable version.

True, but there are also only three relevant engines remaining. Chrome started this, then Firefox adopted it. Other browsers have it mainly because they use Chromium underneath.

It would not surprise me if they also move more in a rapid-release process in the future.

I think it would be a drastic shift away from Apple's current model. They seem to prefer having a roadmap and developer preview in June, a public beta in July, and a release in fall, both for their OSes and their browser. Then minor releases throughout the year.

They could uncouple Safari from iOS, say, but it would introduce complexity into their update process, and Apple traditionally isn't a "well, everyone else does it" kind of company. Everyone else also uses Windows, and x86…
 
They could uncouple Safari from iOS, say, but it would introduce complexity into their update process, and Apple traditionally isn't a "well, everyone else does it" kind of company. Everyone else also uses Windows, and x86…

That's true, but it also mean Apple didn't introduce a rapid-release-like process for their Safari Technology Preview just because "everyone else does it": it means they did see actual benefits in such a process from a development point of view.

Furthermore, Safari Technology Preview is actually pretty much already usable as "default" browser, so I don't consider the switch to a different approach completely unrealistic.
 
That's true, but it also mean Apple didn't introduce a rapid-release-like process for their Safari Technology Preview just because "everyone else does it": it means they did see actual benefits in such a process from a development point of view.

I think they've decided — unlike most other browsers — that such a high-cadence schedule is mainly beneficial for web developers, rather than users at large.

Furthermore, Safari Technology Preview is actually pretty much already usable as "default" browser,

Agreed, although it doesn't have features like syncing tab groups, so I've moved back to regular Safari.

 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.