5 ms·
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 versi
by jl6 8y ago
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?
- aembleton 8y agoJust rebrand the product and then start again at 1.
- laumars 8y agoPeople 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 agoVersion 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 agoSure, 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 agoHow 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 agoLines 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 agoWhat if you come up with a better algorithm for version 7.28 that is 80% shorter?
- catach 8y agoI expect that sometime in the three-digit range projects will typically change to some other versioning scheme.
- aboutruby 8y agoSeems 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.
- rkangel 8y agoWindows (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').