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