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.
Versioning is not the problem with package managers. It's entirely possible to implement a package manager that makes the right choices without changing how we version things. Cargo (Rust's package manager) does just that. That's why I don't think it's necessary to discuss versioning in an article about building a better package manager. Nothing interesting is trivial. That's almost tautological. Calling something out for being non-trivial is either meaningless or equivalent to calling it hard[er than it should be]. In fact, You don't actually need to make the versioning argument at all. I think you can make the exact same point made in the 3 paragraphs following my quote with the following single sentence: "By making the major version number part of the package name and combining the minor and patch numbers, we get a versioning system where the user is forced to pick a major version and can expect to always use the latest patch to that version". There are practical reasons why I disagree with the sentence above, but I think it does a pretty good job of making the same point you made in your article in less than half as many words.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.
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".
Yes, I'm not familiar with Rust, and I've been meaning to learn more there. The best response to my post thus far started off with a description of how Rust has successfully policed SemVer, and the issues they ran into: https://news.ycombinator.com/item?id=15676691#15677343. I'd greatly appreciate further pointers to how that community does things. > Nothing interesting is trivial. That's almost tautological. Calling something out for being non-trivial is either meaningless.. I just provided a trivial alternative that I found interesting. So much for your "tautology". > ..or equivalent to calling it hard[er than it should be]. I do call it harder than it should be, by providing a simpler alternative. It doesn't look like you disagree that a tuple is easier for the package manager to unpack than a string. You seem to be only saying that the difference isn't much. I've already agreed with that. So what are we arguing about? --- I have a problem with the statement that "nothing interesting is trivial": it becomes license for hiding over-engineering. I'd rather say that "everything can be trivial". It's right about the same fraction of the time, and even when it's wrong it's an impetus to find better ways, rather than to be complacent. I spend some time teaching programming, and it's amazing to me how often finding the right approach to teach something renders it almost trivial. See also Alan Kay's statement about the right perspective being worth 80 IQ points. --- I have a problem with statements as general as "nothing interesting is trivial" (Or, indeed, "everything can be trivial".) They aren't concrete enough to actually support any serious amount of reasoning. You can end up anywhere you like depending on how you interpret them. This comment is about as much of such fluffy debate as I can handle without breaking out in hives. --- Seriously, stop nit-picking wording in one sentence I quickly moved past in OP. It's mystifying to me why that's a better use of your time, rather than to elaborate on the "practical reasons" you so quickly skip past. I'm going to stop engaging here unless it is to discuss more substantive criticisms.