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.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.
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.
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.
That works for libraries, but applications? What is the interface you’re looking at for backwards compatibility? Towards websites, towards workflows, towards CLI arguments, towards ABI, or something else?
There’s also the disadvantage of being perceived as moving slower than the competition. If Chrome is at v162 and you’re at v3, people perceive the version numbers to reflect the quality and development. Shouldn’t be the case, but it is.
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.
I think you have a misconception about what Semver is. No, changing private interfaces does NOT increase major version - why do you think that Semver specifies that you must declare a public API? This would also mean any bugfixes would result in major bumps, but they don’t, because not every interface change is treated equally.
You also skipped the actual question. What are all of Firefoxes interfaces? Is user flow itself an interface?
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.
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.
That works for libraries, but applications? What is the interface you’re looking at for backwards compatibility? Towards websites, towards workflows, towards CLI arguments, towards ABI, or something else?
There’s also the disadvantage of being perceived as moving slower than the competition. If Chrome is at v162 and you’re at v3, people perceive the version numbers to reflect the quality and development. Shouldn’t be the case, but it is.
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.
I think you have a misconception about what Semver is. No, changing private interfaces does NOT increase major version - why do you think that Semver specifies that you must declare a public API? This would also mean any bugfixes would result in major bumps, but they don’t, because not every interface change is treated equally.
You also skipped the actual question. What are all of Firefoxes interfaces? Is user flow itself an interface?