I agree that the article needs to change something. I'm not a good writer yet, and I definitely failed to get my point across to many (most?) readers. But I don't think separating package managers from the discussion of versioning is a good idea. Versioning is a social convention (as evidenced by the quantity of criticism my attempt at changing convention has engendered), and the #1 place the convention is propagated is in the package manager. You can in principle implement every one of my recommendations (or any alternatives people proposed in comments) without changing the package manager. But of course nobody would expect that to take. The big insight that provoked my post was that the bad behaviors the creators of Clojure and Mercurial were complaining about stemmed from bad defaults in package managers. > "3.0.2" is hard to parse? Are you serious? If this was the only sentence-level criticism you could make I'm not doing so bad :) Notice that I said "non-trivial", not "hard". In a tool whose #1 reason for existence is to "get the latest version", it seems a bad idea to make the format of version strings unstructured in code (they're literally strings surrounded in quotes) or convention (people are encouraged to add arbitrary words to them). Why make comparison unnecessarily difficult? I'm talking about creating a package manager from scratch (I'm not proposing every package manager break their users in a post about not breaking your users) for some hypothetical next big language, and in that situation it seems worth fixing even if it's not that big a deal. > The software I write for my job has version numbers, even though it isn't distributed through any package manager. My recommendation may absolutely not apply then. If your software isn't ever being upgraded en masse I have no opinion on what versions it should have. I'm speaking in the context of eco-systems that want to be able to distribute security fixes (at the least) on an ongoing basis. That's what the two links I was putting together were talking about, and that usually involves a package manager to automate the upgrade process.