I dunno, man; I'm not a programmer but I'm on three different closed NDA betas (and four or five open ones) and the process is exactly this: PRO TOOLS 12.8.2x147 Where - "12" is the version Marketing is using for an overarching major paradigm change with major improvements (v12 has track freeze, a new video engine, a rewritten audio engine and robust improvements to the workspace) - ".8" is the version Marketing is using for a bundled suite of improvements over .7, for example (predictive labeling, revised I/O manager, etc) - ".2" is the version Engineering is putting out of assorted bug fixes and minor improvements - "x147" is the internal build number we're all working on to try and break/fix prior to release candidate and gold master for distribution to all users Anything that works with 12.1 will work with 12.7 will work with 12.8, but there will be compatibility issues with 11. Meanwhile, 12.8.2 is going to be an incremental improvement over 12.8.1 and the xVersions nobody external is going to see anyway. And it works just fine. I mean, we all know that the best performance we ever got was 7.4.2 but we also know that it ran on RISC processors and used a plugin structure we abandoned in 2009 and that was back before we were expected to work with 150 tracks on a bloody short film. Again - not a programmer but this stuff makes perfect sense to me.
I am a programmer, and I have to agree. The current scheme of dotted numbers works just fine. Everything mentioned in this post falls into two categories. 1) Package managers should be better at automatically figuring out what version I want. 2) Version strings are should be easier to parse. (1) is a fair complaint. It's certainly possible to build a better package manager, but you don't need to mess with versioning to do it. (2) is really just arguing semantics. I personally disagree with akkartik, but it's a fundamentally subjective argument.
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.