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.
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.
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.
If Chrome is at v162 and you’re at v3, people perceive the version numbers to reflect the quality and development.
I don’t think it is the case. Ask some random person what version their browser is and they probably won’t even know how to check.
It doesn’t matter for the vast majority of people, the only people who care are power users. And what do power users appreciate? Clear communication. If there’s a major UI change or something, bump the major version. If there’s a new feature, bump the minor version. If it’s just bug fixes, bump the patch version. Or even simpler, since Firefox has the ESR build, bump the major version whenever an ESR build is cut, bump the minor version every regular release (4 weeks?), and bump the patch version every patch release like we do now. That way I know how much the ESR build has deviated from the regular build, which is valuable information (just look at the minor version for the latest Firefox).
How you manage versions doesn’t matter to the vast majority of people, so it should be tuned for the minority who actually kind of care, so make it mean something. A year would be fine and useful, a number that increases w/ the ESR refresh would be useful, an ever-increasing number isn’t useful. Pick one of the useful options…
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?
You are correct about private interfaces. When I wrote that I was imagining something more significant like a code refactor, but yes, obviously, changing something like an internal function definition would not require a new major version if it doesn’t change a public interface. Similarly, implementing a bugfix or new feature wouldn’t necessarily mean that an existing public interface was broken, or that the major version should be incremented. I didn’t intend to imply that.
I am using public interfaces in my examples because the original point was how SemVer can communicate at a glance to the end user the kinds of changes that were made (compatibility-breaking, bugfix, etc.) and I had the offhand idea to also communicate when the update was released by including the date in the patch number. I am not confused about what semantic versioning is or whether it can only apply to public interfaces or libraries. If I knew it was going to start an argument, I wouldn’t have mentioned backwards compatibility; it was an offhand comment tangential to the idea I was explaining. I could have just as easily said:
“I prefer the SemVer Major.Minor.Patch approach so I can tell at a glance if the update is a new feature release or is just bug fixes”.
I don’t think I skipped the question about Firefox interfaces. An interface I was looking at for backwards compatibility was in the example I provided with the UserChrome interface and I provided a specific example of a third party tool using that interface, the FireFox-UI-Fix project. Admittedly, this isn’t a strong example because the UserChrome customization doesn’t expose any functions to be called and doesn’t define any kind of protocol in a traditional sense. But that doesn’t make it any less of an interface in my opinion.
The UserChromeCSS customization feature is provided to the user by Mozilla for the purpose of modifying the browser’s chrome i.e. graphical user interface (note I’m not confusing a gui with a programming interface, they just happen to be the same thing in this example). In order to make these customizations, the user must be aware of how the browser’s gui is layed out, i.e. the user must know the structure of the HTML that makes up the browser’s chrome. If the user writes a gui customization which depends on that structure for one version of the web browser but then the browser changes that HTML structure in the next update, that constitutes a breaking change. In this example the interface is defined by the chrome’s HTML itself. The CSS written in the UserChrome.css references/selects that HTML and is thus dependent on the stability of that HTML in order to produce the same effects across different versions of the web browser. Third-party tools that distribute custom UserChrome.css files should therefore expect that their customizations be compatible across minor and patch versions of the same major version release. It’s not necessarily that the major version must increment every time this gui is changed, but when the interface for customizing this gui has introduced a breaking change (which in this case is usually synonymous). I think this is what you mean when you say “userflow”. If so, then no, I don’t think “userflow” is an interface. The userflow/gui happens to be an interface in this example because of the UserChrome feature that exposes the gui to modification through its own HTML/CSS interface, the stability of which is depended upon by both users and third-party developers such as the Firefox-UI-Fix project I mentioned.
As for other Firefox interfaces which would call for a major version increment upon being changed, there is the WebExtensions API for browser extensions, and the cli arguments that you mentioned. I don’t think providing an exhaustive list supports or invalidates any point or opinion I’ve stated. The major version number is incremented if any public interface changes, it doesn’t have to be representative of a single interface exclusively. An application can provide multiple public interfaces, where a library tends to be more singularly focused (maybe this is the source of our disagreement/misunderstanding?). An incremented major version just means that there is some breaking change(s) in some interface(s). Conversely, an incremented major version number doesn’t imply that every provided interface contains a breaking change.
If it’s your opinion that SemVer is better suited to a narrow API or library where a new major version exclusively indicates a breaking change in its singular public interface. Ok. That doesn’t indicate a lack of understanding SemVer on my part, and that’s not a requirement of SemVer. There exist applications using SemVer that expose multiple interfaces.
When I wrote that I was imagining something more significant like a code refactor,
Again, a code refactor is not a change in public API and thus does not constitute a semver major bump.
I’d like to have written a more constructive reply, but with most of your comment consisting of explanations with arguments couched in I’m not interested enough to parse out what is what, sorry. Don’t know why you explain UserChrome.css to me.
The claim wasn’t that a code refactor is always a change in public interface, but that it could constitute a new major version. I listed two examples of when a major version should be incremented, the first being a change in a public interface, the second (erroneously) was a change in a private interface which I then clarified could only apply in the case of a more substantial code refactor, because as you pointed out (and I reiterated and agreed with), private interface changes don’t necessitate breaking changes. It isn’t an exclusive requirement that a public interface has breaking changes in order for the major version to be incremented, only that there be a new major version when that interface breaks introduces breaking changes.
I had to explain userchrome thoroughly in order to demonstrate that it is a public interface and differentiate it from the gui. I assumed it wasn’t intuitive because you missed it when I provided it as an example initially and was accused of avoiding that point.
The first sentence of each paragraph addresses which point it argues other than the userchrome demonstration which follows from the prior paragraph and only addresses your userflow vs interface question in its conclusion.
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.
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.
I don’t think it is the case. Ask some random person what version their browser is and they probably won’t even know how to check.
It doesn’t matter for the vast majority of people, the only people who care are power users. And what do power users appreciate? Clear communication. If there’s a major UI change or something, bump the major version. If there’s a new feature, bump the minor version. If it’s just bug fixes, bump the patch version. Or even simpler, since Firefox has the ESR build, bump the major version whenever an ESR build is cut, bump the minor version every regular release (4 weeks?), and bump the patch version every patch release like we do now. That way I know how much the ESR build has deviated from the regular build, which is valuable information (just look at the minor version for the latest Firefox).
How you manage versions doesn’t matter to the vast majority of people, so it should be tuned for the minority who actually kind of care, so make it mean something. A year would be fine and useful, a number that increases w/ the ESR refresh would be useful, an ever-increasing number isn’t useful. Pick one of the useful options…
All the feedback and attempts at studies I’ve seen point in the opposite direction, don’t know what to tell you.
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?
You are correct about private interfaces. When I wrote that I was imagining something more significant like a code refactor, but yes, obviously, changing something like an internal function definition would not require a new major version if it doesn’t change a public interface. Similarly, implementing a bugfix or new feature wouldn’t necessarily mean that an existing public interface was broken, or that the major version should be incremented. I didn’t intend to imply that.
I am using public interfaces in my examples because the original point was how SemVer can communicate at a glance to the end user the kinds of changes that were made (compatibility-breaking, bugfix, etc.) and I had the offhand idea to also communicate when the update was released by including the date in the patch number. I am not confused about what semantic versioning is or whether it can only apply to public interfaces or libraries. If I knew it was going to start an argument, I wouldn’t have mentioned backwards compatibility; it was an offhand comment tangential to the idea I was explaining. I could have just as easily said:
I don’t think I skipped the question about Firefox interfaces. An interface I was looking at for backwards compatibility was in the example I provided with the UserChrome interface and I provided a specific example of a third party tool using that interface, the FireFox-UI-Fix project. Admittedly, this isn’t a strong example because the UserChrome customization doesn’t expose any functions to be called and doesn’t define any kind of protocol in a traditional sense. But that doesn’t make it any less of an interface in my opinion.
The UserChromeCSS customization feature is provided to the user by Mozilla for the purpose of modifying the browser’s chrome i.e. graphical user interface (note I’m not confusing a gui with a programming interface, they just happen to be the same thing in this example). In order to make these customizations, the user must be aware of how the browser’s gui is layed out, i.e. the user must know the structure of the HTML that makes up the browser’s chrome. If the user writes a gui customization which depends on that structure for one version of the web browser but then the browser changes that HTML structure in the next update, that constitutes a breaking change. In this example the interface is defined by the chrome’s HTML itself. The CSS written in the UserChrome.css references/selects that HTML and is thus dependent on the stability of that HTML in order to produce the same effects across different versions of the web browser. Third-party tools that distribute custom UserChrome.css files should therefore expect that their customizations be compatible across minor and patch versions of the same major version release. It’s not necessarily that the major version must increment every time this gui is changed, but when the interface for customizing this gui has introduced a breaking change (which in this case is usually synonymous). I think this is what you mean when you say “userflow”. If so, then no, I don’t think “userflow” is an interface. The userflow/gui happens to be an interface in this example because of the UserChrome feature that exposes the gui to modification through its own HTML/CSS interface, the stability of which is depended upon by both users and third-party developers such as the Firefox-UI-Fix project I mentioned.
As for other Firefox interfaces which would call for a major version increment upon being changed, there is the WebExtensions API for browser extensions, and the cli arguments that you mentioned. I don’t think providing an exhaustive list supports or invalidates any point or opinion I’ve stated. The major version number is incremented if any public interface changes, it doesn’t have to be representative of a single interface exclusively. An application can provide multiple public interfaces, where a library tends to be more singularly focused (maybe this is the source of our disagreement/misunderstanding?). An incremented major version just means that there is some breaking change(s) in some interface(s). Conversely, an incremented major version number doesn’t imply that every provided interface contains a breaking change.
If it’s your opinion that SemVer is better suited to a narrow API or library where a new major version exclusively indicates a breaking change in its singular public interface. Ok. That doesn’t indicate a lack of understanding SemVer on my part, and that’s not a requirement of SemVer. There exist applications using SemVer that expose multiple interfaces.
Again, a code refactor is not a change in public API and thus does not constitute a semver major bump.
I’d like to have written a more constructive reply, but with most of your comment consisting of explanations with arguments couched in I’m not interested enough to parse out what is what, sorry. Don’t know why you explain UserChrome.css to me.
The claim wasn’t that a code refactor is always a change in public interface, but that it could constitute a new major version. I listed two examples of when a major version should be incremented, the first being a change in a public interface, the second (erroneously) was a change in a private interface which I then clarified could only apply in the case of a more substantial code refactor, because as you pointed out (and I reiterated and agreed with), private interface changes don’t necessitate breaking changes. It isn’t an exclusive requirement that a public interface has breaking changes in order for the major version to be incremented, only that there be a new major version when that interface
breaksintroduces breaking changes.I had to explain userchrome thoroughly in order to demonstrate that it is a public interface and differentiate it from the gui. I assumed it wasn’t intuitive because you missed it when I provided it as an example initially and was accused of avoiding that point.
The first sentence of each paragraph addresses which point it argues other than the userchrome demonstration which follows from the prior paragraph and only addresses your userflow vs interface question in its conclusion.