- #Easy numbering by hand how to#
- #Easy numbering by hand mac os#
- #Easy numbering by hand upgrade#
- #Easy numbering by hand software#
10.16 ? Just another boring release for macOS. Major releases are good because they show innovation: that we are continuously improving our product instead of just pushing our patches.
#Easy numbering by hand upgrade#
Minor releases are good because customers upgrade easily and we do not have to support all those old versions. But marketing decided to number it 21.3.5 instead of 22.0. Again irrespective of content: a minor release may contain major functionality and breaking changes. Means: let’s delay the upgrade until we have fully tested everything for any regressionĬhange the minor release ? It has just fixes, so let’s just upgrade. It is a dilemma for marketing, irrespective of actual content.Ĭhange the major release ? That frightens customers, especially in enterprise environments. Version numbering has always been a headache, especially the concept of major vs minor release.
#Easy numbering by hand mac os#
If Apple has returned to the version numbering which it used before Mac OS X, that update should be 11.1, and then next summer we should all be enjoying 12.0 beta. What Apple hasn’t yet made clear, as far as I can tell, is which version of macOS will be the first update to Big Sur a couple of months after the release of 11.0. The alternative is just to say to hell with it all, and look for either 10.16 or 11.0, knowing that your code should be safe for a while. If you really want to be sure of getting a consistent version, then don’t read ist but ist: macOS doesn’t pull any tricks with that, and you’ll always get 10.16 when running on Big Sur.
SYSTEM_VERSION_COMPAT=0 cat /System/Library/CoreServices/istĪlthough both should read the same file, in the first case you’ll be shown the contents of ist instead, where ProductVersion isn’t 11.0 but 10.16. SYSTEM_VERSION_COMPAT=1 cat /System/Library/CoreServices/ist You can test this at the command line, by entering the two commands If the caller has set SYSTEM_VERSION_COMPAT=1, then the version number returned isn’t obtained from that property list at all, but its companion ist, which is 10.16. However, depending on the environment of the caller, Big Sur plays tricks with that file, which should return a version of 11.0. One method commonly used to look up the macOS version number is to obtain the string value for the ProductVersion key in /System/Library/CoreServices/ist. This is where it gets less well-defined, and I’m grateful to for drawing attention to the problem with languages like Python. If you’re unsure of which SDK version your development tools use, contact the supplier. These are also straightforward, as you get what you ask for: set SYSTEM_VERSION_COMPAT=1 for 10.16, or leave that variable unset for 11.0.Īny language compiled outside the Xcode SDK should be built against an SDK equivalent, and the first rule applies. Thus, AppleScript apps should get what they expect, according to the SDK against which they’re built. Returns 11.0, as will that code inside an AppleScript app built on Big Sur.īuild an AppleScript app on 10.15, though, and when that runs on Big Sur, it sees the system version as 10.16. Move a script across to Big Sur, and it will be compiled in the 11.0 environment, so
#Easy numbering by hand how to#
This is a good example of knowing how to interpret those rules. Set SYSTEM_VERSION_COMPAT=1 and Big Sur returns 10.16 leave that variable unset, or SYSTEM_VERSION_COMPAT=0, and it returns 11.0.
When built against the 10.15 SDK or earlier, Big Sur returns 10.16 for compatibility with previous numbering and all existing apps when built against the 11.0 SDK, it returns 11.0 for forward compatibility.