Hacker News Reader

Comment by jl6 | Hacker News Reader

I always wondered if in the far future there is a semantic wasteland waiting for apps that rapidly increase their version number. The difference between a version 65 and a version 66 is fairly manageable for average humans, just in terms of length of the number. But what about when comparing version 19753 and version 19754?

View on HN

Just rebrand the product and then start again at 1.

You mean 'one'.

Chrome The First

Linu XI

Windows (particularly during beta cycles) uses the build number as the version. They are usually things like '2574', and it never seemed a problem.

On the other hand, there was no continuous delivery - you were only receiving a subset of the builds (so maybe '2341' followed by '2784').

I expect that sometime in the three-digit range projects will typically change to some other versioning scheme.

Seems like then the version numbers would become almost irrelevant. And that's what Chrome is gearing towards. The vast majority of people don't know which Chrome version there are running and they don't care because it auto-updates.

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.

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.

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.

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.

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.

What if you come up with a better algorithm for version 7.28 that is 80% shorter?

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.)

One of my favourite Apple history anecdotes:

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%.

> 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?

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.

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).

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.

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.

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.

Reply on news.ycombinator.com