Large projects have been going to regular scheduled releases for a long time. Until the 90's people thought they could waterfall a large release with all your desired features (and for tiny projects this is still a good idea), but as your projects grow (possibly just to small) you reach a point where someone is always working on a feature that isn't ready yet, so a regular release means you still can support your customers with releases. This forces developers who are unsure they will be ready to have some sort of "disabled this unstable feature" toggle, which is about the best you can do.
Yup. OpenJDK is one of the best success stories of this.
Up until Java 9, they would release once features were complete. But that meant there were years between the 7 and 8 release and even more years between the 8 and 9 release.
The industry had gotten into the habit of always running old versions of Java (my company was on 6 for an uncomfortable amount of time. But others have had it worse).
More frequent smaller releases has gotten companies more into the habit of updating frequently which also, very helpfully, gives devs new features frequently.
Sorry to derail...but that brought up some bad memories. The networking company Wellfleet (became Bay Networks thru merger with Synoptics, then died as a chunk of Nortel Networks) had a management tool called 'Site Manager' (SM, aka 'Site Mangler' aka 'S&M').
SM was a monstrous Java app that papered over the (horrifying) fact that everything on a Wellfleet router was configured with SNMP (full-body shiver). Oh, there was a CLI, but even a hard-core CLI pilot like myself couldn't face stuff like "set wflplnterfaceEntry.2.192.168.10.10.3 1" all day long.
Wellfleet clearly employed no software engineers, only monkeys that hammered on keyboards and piled cruft upon cruft to the SM codebase. The end result was that every release of Wellfleet device code (down to point releases) relied on a particular version of SM, which, of course, relied on a particular version of Java.
Now, since virtually no site over a certain size could count on every device running the same version of code, you had to be able to switch between a couple of versions of Java to run a given version of SM. And, as a consultant to Wellfleet shops, I had to be able to run all of them. I got really good at multibooting Windows, but in the end I had a 'Wellfleet' laptop modified a bit so I could easily pop it open and swap disks, each one for a different version of SM running on a different version of Java.
The Linux kernel is another example. The 2.5 development cycle (which led to the stable 2.6 series) was brutally long, and distros resorted to back-porting new features into their own kernels based on the stable 2.4 series that they provided to their users, creating all kinds of excitement. After 2.6.0 was released, Linus basically went nope, not gonna do that again.
And this is why I prefer a "hybrid" version scheme between CalVer & SemVer: A series number to allow LTS releases, a period, a hyphenated datestamp, optional "flag" letters "B" for breaking changes, "S" for security fixes, "F" for new features (more than one can be present, always in that order), and if more than one release is made on the same day the second & subsequent releases get a period followed by a release number starting from 1.
E.g. 3.2026-05-01FS for a first release of the day with a new feature & security fix to release series 3, 2.2026-05-01S backporting the security fix to release series 2 (LTS, say), 3.2026-05-02 for a "bug fixes & performance improvements" release, 3.2026-05-02S.1 for a security fix to the "bug fixes & performance improvements" release.
Like SemVer, this lets users know when there are breaking changes to an API or such, which releases contain security fixes, which releases have new features, and allows multiple simultaneous release versions for LTS support. Like CalVer it lets users know how recent a release is, and makes it pretty easy to figure out what the release schedule was historically (and likely still is) by comparing versions.
Are there any large projects that are older than 25 years that didn't go through that? The time based release thing as been recommended for about 25 years (can anyone get real data?), so newer projects may just be using it without knowing the pain, but for older projects it seems like they all went through it at least once.
For many years that was the only version that could be used. What become gcc3 took years. In the end it was better, but for a while gcc 2.95 was the best we had despite the bugs.
Yeah, GCC’s recent major releases have been remarkably regular, much like Fedora’s spring releases, and their releases seem to fit into the same broader rhythm. Hint? Red Hat.
That is why egcs was launched, to get around the inability of the old team to do gcc releases. The issues had little to do with ideology and were about fixing a broken process and replacing it with something that had a hope of working.