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.
Yes, especially for applications, and especially for Firefox. The Major version in SemVer increases with any interface change public or private (or it’s supposed to). This is important to communicate to users who rely on any 3rd party plugins, or who need to open files created with prior versions of the software, including configuration profiles.
Using Firefox as an example, I use the Firefox UI Fix. If Firefox changes their browser userchrome/layout, this mod breaks. But it is nice that I can tell at a glance when a new Minor version or Patch version releases that it contains no changes that break this mod. Any breaking changes in these versions are bugs in Firefox.
As for higher number versioning. I’m not advocating that Firefox restarts their Major versioning number back to 0. They could skip Major versions and call the next Major version 200 for all I care. The only thing my comment advocated for was including the date in the patch version number.