5 ms·

Interestingly, Apache is roughly twice as old as SemVer (dating SemVer using the Wayback Machine looking at semver.org). I'd have guessed SemVer was younger tha

Interestingly, Apache is roughly twice as old as SemVer (dating SemVer using the Wayback Machine looking at semver.org). I'd have guessed SemVer was younger than that, but time is weird. Incidentally, that means that Apache is not, in fact, using SemVer. They're using the old-school even-odd system.

secondcoming 3y ago
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.
brianm 3y ago
Apache uses [APR Versioning](https://apr.apache.org/versioning.html https://apr.apache.org/versioning.html) which I think had a big influence on semver, fwiw

secondcoming 3y ago

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.

brianm 3y ago

Apache uses [APR Versioning](https://apr.apache.org/versioning.html https://apr.apache.org/versioning.html) which I think had a big influence on semver, fwiw