this post was submitted on 05 Nov 2024
56 points (98.3% liked)

Firefox

17880 readers
107 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
[–] [email protected] 8 points 1 week ago (12 children)

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.

[–] [email protected] 7 points 1 week ago* (last edited 1 week ago) (11 children)

I prefer the SemVer Major.Minor.Patch approach so I can tell at a glance if the update breaks compatibility or is just bug fixes. Technically the Patch part can be any number as long as it increases each update of that same Minor version, so one could write the versions as AA.BB.YYMMXX where AA is the Major version, BB is the Minor, YY is the two digit year, MM is the month, and XX is just an incrementing number.

I think this approach has the best of both systems.

[–] [email protected] -1 points 6 days ago (2 children)

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.

[–] [email protected] 1 points 6 days ago

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.

load more comments (1 replies)
load more comments (9 replies)
load more comments (9 replies)