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.