5 ms·

People need to stop thinking about version numbers as being something meaningful. Particularly in the era of package managers, CI pipelines and version pinning.

People need to stop thinking about version numbers as being something meaningful. Particularly in the era of package managers, CI pipelines and version pinning. eg many places would could use git commit hashes where the latest is pulled in by the CI pipeline for testing on the dev environments and then prod is version pinned to a specific hash until testing has vetted a newer commits as being safe for deployment. edit: I'm curious why I'm getting so heavily down voted when the evidence is clearly there that the majority of projects versioning is completely arbitrary. Sure, there are some notable exceptions but when you're building complex secure systems you are often forced down the version pinning route with controlled and tested deployments for a great many software components.

yjftsjthsd-h 8y ago
Version numbers certainly can be meaningful. They're frequently not used that way, but ex. semver is genuinely quite useful when people actually use it.
- laumars 8y ago
  Sure, there will always be exceptions and I do agree that in those instances version numbering can be meaningful. However different projects follow different conventions and some projects don't even have a formal convention at all. So from a user perspective it's safer to assume no meaning for the majority of projects. Particularly when dealing with smaller community packages / modules pulled in from Puppet / npm / Go / whatever developer or DevOps tooling your project or business has adopted. I'm really less concerned about larger projects like Apache which have a clear published versioning strategy because they're also the kind of projects that are less likely to bite you when doing what should be safe updates within minor / bugfix versions.
- simonh 8y ago
  How about incrementing the version number by an amount proportional to the lines that have changed in the code base. So 10% of lines have changed and 20% of lines have been added, so increment version number from 5.6 to 7.28.
  - laumars 8y ago
    Lines of code are even less meaningful than version numbers. There are some good standards out there for versioning. But honestly the best thing you can do as a developer or sysadmin is to treat every version update like a breaking change and run it through your dev and test environments before pushing to prod.
  - badsectoracula 8y ago
    What if you come up with a better algorithm for version 7.28 that is 80% shorter?
    - yjftsjthsd-h 8y ago
      Just use the absolute value. An 80% decrease is a big change just like an 80% increase. (To be clear: I disagree with the suggestion, I just don't think this is a strong argument against it.)
    - simonh 8y ago
      One of my favourite Apple history anecdotes: https://www.folklore.org/StoryView.py?project=Macintosh&story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?project=Macintosh&stor... With my tongue firmly still in my cheek, I'd say increment the version number by the difference. So if you deduct 5% of the code and add another 15%, then increment the version number by 20%.
chrisseaton 8y ago
> People need to stop thinking about version numbers as being something meaningful. If they don't mean anything then get rid of them! Of course they mean something. They (almost always) uniquely identify a particular release of the software. What do you use to do that instead?
- laumars 8y ago
  I can't tell if your comment is serious or not but in any case you're completely missed my point. I'm talking about people who assume version 2.1 means something different from a version 1.2. Developers can bump version numbers in any which way they want and while some projects to have a documented standard for versioning; most projects do not. So consumers of software shouldn't base judgements solely on which digit is incremented in a version string.
  - jeltz 8y ago
    Bu9t if you know the project they can be meaningful. E.g. how many Rust libraries make a decent effort at following SemVer or how the two digits of PostgreSQL have very specific meanings which always are respected (the first digit is the major version which may contain new features and break APIs while the second digit is only for bugfixes and is not allowed to introduce any new feature).
    - laumars 8y ago
      The thing is, if you’re running production services, particularly ones that need to be stable and secure, then you need to treat any version update with caution; even point versions on SemVer strings. You’d still need to deploy to dev and test first, you’d still need to do any security scans you’d normally do, etc. The dev community have suffered malware before from point releases being released by new authors. And we’ve seen occasions in the past where a bug fix in a point release has inadvertently broken something else. I guess you can argue that SemVar gives you an estimate about the likelihood something will break which might help when estimating JIRA tickets for the next sprint. But realistically you’d still have to follow a cautious release cycle even for updating point releases when on production environments. This is why I think we need to get past the mindset of treating version strings as something trustworthy. They offer no guarantees whatsoever.
aembleton 8y ago
But it is useful as I can add something like implementation "io.springfox:springfox-swagger2:2.9.+" so that I can get all new point versions but nothing larger so that I don't risk a breaking change.
- laumars 8y ago
  You cannot even guarantee point releases don't contain breaking changes. Nor can you assume they don't include new security vulnerabilities. When deploying software in a production environment you should never deploy anything which hasn't first been tested through your CI pipeline and/or been through it's paces in your dev and test environments before deploying to prod. In fact many engineers running on security systems will version lock even the point release for safety. This is particularly true when working with smaller projects or packages in node / Go / whatever. In fact there was a case recently about someone who took ownership of a popular Python (I think it was) module, inserted malware and just upped the point release. So in summary: no, you cannot even guarantee that point releases are safe.

yjftsjthsd-h 8y ago

Version numbers certainly can be meaningful. They're frequently not used that way, but ex. semver is genuinely quite useful when people actually use it.

laumars 8y ago
Sure, there will always be exceptions and I do agree that in those instances version numbering can be meaningful. However different projects follow different conventions and some projects don't even have a formal convention at all. So from a user perspective it's safer to assume no meaning for the majority of projects. Particularly when dealing with smaller community packages / modules pulled in from Puppet / npm / Go / whatever developer or DevOps tooling your project or business has adopted. I'm really less concerned about larger projects like Apache which have a clear published versioning strategy because they're also the kind of projects that are less likely to bite you when doing what should be safe updates within minor / bugfix versions.
simonh 8y ago
How about incrementing the version number by an amount proportional to the lines that have changed in the code base. So 10% of lines have changed and 20% of lines have been added, so increment version number from 5.6 to 7.28.
- laumars 8y ago
  Lines of code are even less meaningful than version numbers. There are some good standards out there for versioning. But honestly the best thing you can do as a developer or sysadmin is to treat every version update like a breaking change and run it through your dev and test environments before pushing to prod.
- badsectoracula 8y ago
  What if you come up with a better algorithm for version 7.28 that is 80% shorter?
  - yjftsjthsd-h 8y ago
    Just use the absolute value. An 80% decrease is a big change just like an 80% increase. (To be clear: I disagree with the suggestion, I just don't think this is a strong argument against it.)
  - simonh 8y ago
    One of my favourite Apple history anecdotes: https://www.folklore.org/StoryView.py?project=Macintosh&story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?project=Macintosh&stor... With my tongue firmly still in my cheek, I'd say increment the version number by the difference. So if you deduct 5% of the code and add another 15%, then increment the version number by 20%.

chrisseaton 8y ago

> People need to stop thinking about version numbers as being something meaningful. If they don't mean anything then get rid of them! Of course they mean something. They (almost always) uniquely identify a particular release of the software. What do you use to do that instead?

laumars 8y ago
I can't tell if your comment is serious or not but in any case you're completely missed my point. I'm talking about people who assume version 2.1 means something different from a version 1.2. Developers can bump version numbers in any which way they want and while some projects to have a documented standard for versioning; most projects do not. So consumers of software shouldn't base judgements solely on which digit is incremented in a version string.
- jeltz 8y ago
  Bu9t if you know the project they can be meaningful. E.g. how many Rust libraries make a decent effort at following SemVer or how the two digits of PostgreSQL have very specific meanings which always are respected (the first digit is the major version which may contain new features and break APIs while the second digit is only for bugfixes and is not allowed to introduce any new feature).
  - laumars 8y ago
    The thing is, if you’re running production services, particularly ones that need to be stable and secure, then you need to treat any version update with caution; even point versions on SemVer strings. You’d still need to deploy to dev and test first, you’d still need to do any security scans you’d normally do, etc. The dev community have suffered malware before from point releases being released by new authors. And we’ve seen occasions in the past where a bug fix in a point release has inadvertently broken something else. I guess you can argue that SemVar gives you an estimate about the likelihood something will break which might help when estimating JIRA tickets for the next sprint. But realistically you’d still have to follow a cautious release cycle even for updating point releases when on production environments. This is why I think we need to get past the mindset of treating version strings as something trustworthy. They offer no guarantees whatsoever.

aembleton 8y ago

But it is useful as I can add something like implementation "io.springfox:springfox-swagger2:2.9.+" so that I can get all new point versions but nothing larger so that I don't risk a breaking change.

laumars 8y ago
You cannot even guarantee point releases don't contain breaking changes. Nor can you assume they don't include new security vulnerabilities. When deploying software in a production environment you should never deploy anything which hasn't first been tested through your CI pipeline and/or been through it's paces in your dev and test environments before deploying to prod. In fact many engineers running on security systems will version lock even the point release for safety. This is particularly true when working with smaller projects or packages in node / Go / whatever. In fact there was a case recently about someone who took ownership of a popular Python (I think it was) module, inserted malware and just upped the point release. So in summary: no, you cannot even guarantee that point releases are safe.