Looking at the release history for macOS version 15 (“Sequoia”) (skipping the 15.x.1 releases, which probably should remain sequential, since they’re usually just bug-fix releases):
- 15.0 released September 16, 2024
- 15.1: October 28 (6 weeks)
- 15.2: December 11 (6. weeks)
- 15.3: January 27, 2025 (6.5 weeks)
- 15.4: March 31 (9 weeks)
- 15.5: May 12 (6 weeks)
- 15.6: July 29 (11 weeks)
- 15.7: September 15 (7 weeks)
So if we were to do this with year/month versions, we’d get: 24.9, 24.10, 24.12, 25.1, 25.3, 25.5, 25.7 and 25.9. That’s a rather irregular cadence and I think it would lead to many users (and a lot of the press) to start expecting more cadences (with no basis for that expectation) resulting in complaints when the releases come out faster or slower than expected.
Open source projects can do this because they have a policy of “we’re going to snapshot our stable branch on a fixed schedule and release whatever that may be”, and they rapidly drop support for old versions.
For example, Ubuntu puts out a release every 6 months and drops support after 9 months. For those who can’t keep up with this pace, every two years, their April release is tagged “long-term support” and is supported for five years.
But this strategy means that some releases have massive changes, while others may be mostly bug fixes and cosmetic changes. This works fine for a technically-savvy community, but I suspect would confuse others, who generally assume that changes to the major version number means major changes in the product.
This approach also doesn’t play well with companies, like Apple, that want to make big media splashes when new features are rolled out and want (for marketing purposes) to bump the major revision each time this happens.
Microsoft sort-of solved this problem by separating the marketing-name-version from the internal version. We see this looking at their releases, since Windows 10:
- Windows 10:
- Started out with month-stamped versions: 1507 (retroactively applied to what was NT 10.0), then 1511, 1607, 1703, 1709, 1803, 1809, 1903, 1909 and 2004
- After that, switched to calendar-half dates: 20H2, 21H1, 21H2, 22H2
- I assume that’s because the months didn’t always align with the actual release dates. For instance, 1607 shipped on August 2 and 1909 shipped in November. Rather than perform a last-minute change to the internal version, they chose to make the versions fuzzier.
- Windows 11 is doing the same thing.
- They switched the marketing version from 10 to 11 as a part of making changes that broke compatibility with old hardware, but they’ve kept the same version-number sequence from 10.
- It appears, however, that they’ve switched to annual releases (counting the updates in between as just bug fixed and security updates): 21H2, 22H2, 23H2, 24H2, 25H2.
- The current “Windows Insider” preview release is 26H1. I don’t know if it will keep that version when it is released.
I guess Apple could do something like that, but since they like to release major new features and compatibility-breaking changes every year, the result would probably not be much different from what they’re doing now.
In other words, given the way Apple releases software products, I think what they’re currently doing is probably the best of several bad choices.