4 ms·

Version numbers and how they’re used have been around long before someone decided to make a webpage about them and claim some sort of paradigm shift.

hnlmorg 3y ago
While that’s true, the GP is right that semantic versioning is a relatively recent term and a lot of older projects followed a principle of odd numbers being development versions with even numbers being stable releases (Apache 2.3 vs 2.4, PHP used to follow this, Linux kernel used to too, eg 2.4, 2.6). The x number (in x.y.z) was still used to denote a major upgrade but jumps between y were usually considered breaking changes too. It’s also worth noting that it used to be common to have 4 sets of numbers, x.y.z.n with n being automatic build numbers. Lastly, there’s still another common trend to have version numbers based on release date. Ubuntu do this, for example. I personally quite like this approach as it communicates a little more than just a release version. For internal projects I often go even further and recommend a git hash included as part of the release version. So yes, versioning schemes are older than the web. However agreed standards in how to use version numbers have always varied a significantly (and still do now). And the Apache httpd project does predate the rise in popularity of semantic versioning.
- ilyt 3y ago
  I'm not a fan of year numbers being the first number. Stick it at end with git hash IMO. I do like when first number change signals need to read the changelog (as in "backward-incompatible changes"). Semver or not.
  - hnlmorg 3y ago
    It depends on what piece of software your version numbering though. Semver is great for APIs but doesn’t have as compelling strengths for standalone applications, distributions of packages nor operating systems since what constitutes as a “breaking change” becomes harder to define. For something like Ubuntu, signalling the age of a release to end users is more valuable than following semver strictly (not to mention that the patch part of semver wouldn’t even apply). Whereas if your software is being consumed by other software, such as an API, then you need to communicate where interfaces might change in ways that are verifiable via other software interfaces. So it really depends on who is consuming your software interface. You might even want multiple different version schemes for different parts of your application. You’ll sometimes see applications have one versioning scheme for their end user facing interface while their developer APIs, which are still bundled as part of their application, might follow another. Going back to the original point about dates as version numbers, the biggest appeal for me is it takes human error out of the equation. I’ve lost track of the number of companies I have joined which were very good at supporting versioning but terrible at remembering to increment that version number. So having a system which can auto-increment version numbers takes one problem away from developers. And if you’re auto-incrementing private packages then the question becomes: “how strictly are you now following semver?” At which point you might as well have a timestamp and then have the bonus feature of communicating to your team when a specific build was committed. I don’t think there is a right or wrong way to do these things though. You just need to pick a standard, document it and be committed to following it.
    - ilyt 3y ago
      >It depends on what piece of software your version numbering though. Semver is great for APIs but doesn’t have as compelling strengths for standalone applications, distributions of packages nor operating systems since what constitutes as a “breaking change” becomes harder to define. I wrote "changing primary version number" instead of "using semver" on purpose. I agree semver can be too narrow for bigger apps and that is why I only said about signalling "potential sysadmin action required", not signalling new features or bugfixes in version number. > standalone applications, can certainly have "we changed how configuration options work" at the very least > distributions of packages Distros are so far managing that extremely well all things considered > nor operating systems Cue loud Linus yelling about breaking userspace. The OS problem is problem of having different components with different lifecycle.... but my iptables rules are working despise the fact iptables in kernel was entirely replaced by nftables so it certainly can be done just fine.
      - hnlmorg 3y ago
        > I wrote "changing primary version number" instead of "using semver" on purpose. I was making a general point. I wasn’t suggesting you were advocating semver specifically. > can certainly have "we changed how configuration options work" at the very least Any major change to your versioning scheme can signal that. Including having a year number as your major iteration. But what’s more valuable to your end users in these types of scenarios is documentation about the change. > Distros are so far managing that extremely well all things considered You’ve completely lost me now. It sounds like you’re trying to defend Linux distributions but my comment was neither a criticism nor was it about Linux distributions per se. These are plenty of instances where several packages are distributed as a whole. Like with multimedia applications that might ship ffmpeg, a Python scripting environment and a multitude of other components. Linux distros, of course, is another example (and one on a much bigger scale). It’s worth noting that no major distro uses semver either. Some don’t even have a minor release let alone a major version number. But their signalling around versions satisfies a different problem to what an API needs to signal. Hence my point that versioning is about sticking to a standard more than it is about trendy schemas. > The OS problem is problem of having different components with different lifecycle.... but my iptables rules are working despise the fact iptables in kernel was entirely replaced by nftables so it certainly can be done just fine. I don’t really understand your point here but I’m happy for you that your config is still working :)

hnlmorg 3y ago

While that’s true, the GP is right that semantic versioning is a relatively recent term and a lot of older projects followed a principle of odd numbers being development versions with even numbers being stable releases (Apache 2.3 vs 2.4, PHP used to follow this, Linux kernel used to too, eg 2.4, 2.6). The x number (in x.y.z) was still used to denote a major upgrade but jumps between y were usually considered breaking changes too. It’s also worth noting that it used to be common to have 4 sets of numbers, x.y.z.n with n being automatic build numbers. Lastly, there’s still another common trend to have version numbers based on release date. Ubuntu do this, for example. I personally quite like this approach as it communicates a little more than just a release version. For internal projects I often go even further and recommend a git hash included as part of the release version. So yes, versioning schemes are older than the web. However agreed standards in how to use version numbers have always varied a significantly (and still do now). And the Apache httpd project does predate the rise in popularity of semantic versioning.

ilyt 3y ago
I'm not a fan of year numbers being the first number. Stick it at end with git hash IMO. I do like when first number change signals need to read the changelog (as in "backward-incompatible changes"). Semver or not.
- hnlmorg 3y ago
  It depends on what piece of software your version numbering though. Semver is great for APIs but doesn’t have as compelling strengths for standalone applications, distributions of packages nor operating systems since what constitutes as a “breaking change” becomes harder to define. For something like Ubuntu, signalling the age of a release to end users is more valuable than following semver strictly (not to mention that the patch part of semver wouldn’t even apply). Whereas if your software is being consumed by other software, such as an API, then you need to communicate where interfaces might change in ways that are verifiable via other software interfaces. So it really depends on who is consuming your software interface. You might even want multiple different version schemes for different parts of your application. You’ll sometimes see applications have one versioning scheme for their end user facing interface while their developer APIs, which are still bundled as part of their application, might follow another. Going back to the original point about dates as version numbers, the biggest appeal for me is it takes human error out of the equation. I’ve lost track of the number of companies I have joined which were very good at supporting versioning but terrible at remembering to increment that version number. So having a system which can auto-increment version numbers takes one problem away from developers. And if you’re auto-incrementing private packages then the question becomes: “how strictly are you now following semver?” At which point you might as well have a timestamp and then have the bonus feature of communicating to your team when a specific build was committed. I don’t think there is a right or wrong way to do these things though. You just need to pick a standard, document it and be committed to following it.
  - ilyt 3y ago
    >It depends on what piece of software your version numbering though. Semver is great for APIs but doesn’t have as compelling strengths for standalone applications, distributions of packages nor operating systems since what constitutes as a “breaking change” becomes harder to define. I wrote "changing primary version number" instead of "using semver" on purpose. I agree semver can be too narrow for bigger apps and that is why I only said about signalling "potential sysadmin action required", not signalling new features or bugfixes in version number. > standalone applications, can certainly have "we changed how configuration options work" at the very least > distributions of packages Distros are so far managing that extremely well all things considered > nor operating systems Cue loud Linus yelling about breaking userspace. The OS problem is problem of having different components with different lifecycle.... but my iptables rules are working despise the fact iptables in kernel was entirely replaced by nftables so it certainly can be done just fine.
    - hnlmorg 3y ago
      > I wrote "changing primary version number" instead of "using semver" on purpose. I was making a general point. I wasn’t suggesting you were advocating semver specifically. > can certainly have "we changed how configuration options work" at the very least Any major change to your versioning scheme can signal that. Including having a year number as your major iteration. But what’s more valuable to your end users in these types of scenarios is documentation about the change. > Distros are so far managing that extremely well all things considered You’ve completely lost me now. It sounds like you’re trying to defend Linux distributions but my comment was neither a criticism nor was it about Linux distributions per se. These are plenty of instances where several packages are distributed as a whole. Like with multimedia applications that might ship ffmpeg, a Python scripting environment and a multitude of other components. Linux distros, of course, is another example (and one on a much bigger scale). It’s worth noting that no major distro uses semver either. Some don’t even have a minor release let alone a major version number. But their signalling around versions satisfies a different problem to what an API needs to signal. Hence my point that versioning is about sticking to a standard more than it is about trendy schemas. > The OS problem is problem of having different components with different lifecycle.... but my iptables rules are working despise the fact iptables in kernel was entirely replaced by nftables so it certainly can be done just fine. I don’t really understand your point here but I’m happy for you that your config is still working :)