this post was submitted on 05 Nov 2024
54 points (98.2% liked)
Firefox
17840 readers
16 users here now
A place to discuss the news and latest developments on the open-source browser Firefox
founded 4 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
As the release period was reduced to a month, so 0.1 0.2 0.3 began to appear and so every week
I really prefer the Bitwarden approach to versioning, by including the date like
YYYY.MM.DD.whatever. Makes it easy to know how old a version is at a glance, and easier to remember.I prefer the SemVer
Major.Minor.Patchapproach so I can tell at a glance if the update breaks compatibility or is just bug fixes. Technically thePatchpart can be any number as long as it increases each update of that sameMinorversion, so one could write the versions asAA.BB.YYMMXXwhereAAis theMajorversion,BBis theMinor,YYis the two digit year,MMis the month, andXXis just an incrementing number.I think this approach has the best of both systems.
I would never trust a dev defined SemVer as more than a relatively useless indicator of compatibility. I make sure there's proper unit and integration testing to prevent external dependencies breaking production. If it's a major dependency I check the release notes every version.
Eh, I'd much rather have a dev-defined SemVer that's sometimes inaccurate than something that just arbitrarily increases every release. The first provides some information, the second doesn't.
My suggestion is in compliance with standard SemVer as far as I can tell, but yes it is frustrating when apps use versioning that looks like SemVer, but make interface changes in Minor versions and don't really adhere to SemVer.