Yes, if you can't relate with the problems mentioned in the talk and article I linked to, I guess you don't need the solution 🙂 Code shared between closely coupled teams tends to be the easier use case. Have you ever had issues upgrading your personal devices? I remember times when I couldn't get some Rails app running on my laptop after upgrading the OS. Anything like that ever happen to you?
Well now hold on a sec there, chief. Again - I'm not a programmer. But the system as it exists is perfectly parseable by me. Windows 3.0 was very different than Windows 2.0, and Windows 3.1 was a major improvement over Windows 3.1. Windows 3.11 was a refinement of Windows 3.1 and then the marketers got ahold of it and gave us 95, 98, ME, XP, Vista, 7, 8, 10. It seems that you're saying Rich Hickey is A-OK with Microsoft's market-versioning scheme (which, by the way, has devolved into nonsense) while the rest of the world totally gets that 3.1.2 build 8 is ahead of 3.1.1 but is not a stable version of 3.1.2. More than that, you're arguing that if the totally logical, totally deducible hierarchy that everyone else changes because it doesn't work in your corner case and I can't agree with that. OS X 10.0: Cheetah OS X 10.1: Puma OS X 10.2: Jaguar OS X 10.3 Panther (Pinot) OS X 10.4 Tiger (Merlot) OS X 10.4.4 Tiger (Chardonnay) OS X 10.5 Leopard (Chablis) OS X 10.6 Snow Leopard OS X 10.7 Lion (Barolo) OS X 10.8 Mountain Lion (Zinfandel) OS X 10.9 Mavericks (Cabernet) OS X 10.10: Yosemite (Syrah) OS X 10.11: El Capitan (Gala) macOS 10.12: Sierra (Fuji) macOS 10.13: High Sierra This is the best(worst) of both worlds - I know beyond a reasonable doubt that 10.13 came out after 10.12 while marketers can trumpet the wonders of "High Sierra." But god help you if your mother asks why she needs to upgrade from a beach to a mountain in order to keep Quicken working. Also, why is 10.6 snow leopard but 10.7 is lion? Is 10.6 actually 10.5.5 but 10.7 is... 10.6? Maybe we should just call it "Gumpy Gnu" or whatever. 17.04, I'm told, is "Zesty Zumpus" or some dumb thing but 17.10 is Artful Aardvark, which anybody with any sense will know is more advanced than Dapper Drake because it's been 10 years. And yeah - I know that if I update the version of anything it's likely to break something. After all, I've got three macs and a PC in the house. And when I know that Path Finder is approved through 10.12, I'm not about to update to 10.13 until I know beyond a reasonable doubt that the software I depend on works with it. It's a lot easier to know that 10.12 is after 10.11 than to know that Sierra is after El Capitan.The correct way to practice semantic versioning is without any version strings at all, just Rich Hickey's directive: if you change behavior, rename.
OS X 10 beta: Kodiak
Sorry, yes you're absolutely right and I'm being unclear. I'm a reasonable programmer but not a good writer. When I say "rename" I don't mean going from "Snow Leopard" to "El Capitan". That's stupid, yes. (And it's also marketing, which I know even less about. So I have no comment on what an improvement would be.) My proposal is going from "Rails-4" to "Rails-5". Which would have the same benefits as 10.11 and 10.12. The comments I've gotten so far are making clear that I failed to set the stage for this post. The scenario I'm concerned about (as are the links I refer to) is this: you have an app you built, and it relies on some versions of other libraries. You'd like to periodically pick up bugfixes and security fixes for those libraries without it turning into a bottomless time-sink (because your libraries failed to adequately distinguish between compatible and incompatible changes). How do we do that? (It's not just about tool design, it's about eco-system design.)
Rails-4 to Rails-5 kicks the crap out of Snow Leopard to El Capitan. So the full name would be Ruby Rails-5? I understand the problem you're grappling with now. Beyond my expertise: If you're compatible with Rails-4, for example, and Rails has been upgraded to Rails-5, is there any way to know whether or not you have an incompatibility issue without diving into the changelog anyway? I can see a few different ways that becomes a bottomless time-sink no matter how clean your versioning nomenclature is.
The convention programmers have long followed is now enshrined as something called Semantic Versioning (which comes with its own version, lol). Basically if a library makes an incompatible change it's supposed to increment the major version. So going from Rails 4.x to Rails 5.0 is a sign that you can't upgrade. Which is great in theory, except that the tools we programmers use to manage versions don't understand SemVer and just pick the latest version by default. Which causes programmers to explicitly ask for the version they want to avoid moving to the next. And all the 'pinning' in turn causes libraries to be less than disciplined about incrementing the major version number when they break something. So it's all a mess.