![]() ![]() “ macOS major version is greater than or equal to 11” In this example, I’m testing for a condition that means either: Here’s a shell example on how this might be used: Patch Version: /usr/bin/sw_vers -productVersion | /usr/bin/cut -d. Minor Version: /usr/bin/sw_vers -productVersion | /usr/bin/cut -d. Major Version: /usr/bin/sw_vers -productVersion | /usr/bin/cut -d. Here is one way to do this going forward in a shell language: However in shell scripting languages, it is much easier to just focus on splitting the version number into different groups since most admins will be familiar with the marketing version compared to dissecting the build numbers. These are going to be very welcomed changes going forward because right now once macOS has hit the last minor update the only way to determine if it was on the latest version was to look at the build number of the OS. Although not impossible, it’s a little less straight forward to compare a mix of alphanumeric characters vs integers. Here’s a really good blog post by Armin Briegel: that covers OS versioning and build numbers in more detail. To highlight the issue a bit more clearly, a “supplemental update” would in the past would usually mean we’d go from macOS 10.15.5 to macOS 10.15.5 with the only way to know the difference being the build number which has always been incremented. That’s a simple change to track in most version comparison logic found in programs or scripts. If macOS 11.0.0 releases today and a “supplemental update” needs to come out a few days later then that’s really just a patch and the macOS version would increment from 11.0.0 to 11.0.1. However when macOS gets its minor OS releases that tend to come out every 6-8 weeks then we might go from say 11.1.0 to 11.2.0. Presumably if the same behavior from iOS comes to macOS, the days of “supplemental updates” should be no more. ![]() This would mean that macOS 11 would then move on to macOS 12 by the end of 2021. Obviously, we cannot know for sure what next year may bring, but I’m hoping that Apple sticks to these changes and continues to increment the macOS major version as it has on its other platforms. ![]() PATCH version when you make backwards compatible bug fixes. MINOR version when you add functionality in a backwards compatible manner, andģ. MAJOR version when you make incompatible API changes,Ģ. I propose using the following semantic version guidance on how to refer to 3 digit group separated versions from :ġ. This changes things a bit and I’m proposing that it’d be great if other IT admins used similar naming convention when referring to the the variable names representing each digit group should you need to split each value up. We do have a point of reference on how these changes should go if we look at iOS, iPadOS, tvOS, and watchOS which have 3 digit versions. With macOS 11, it’s going to be important to check all 3 digit groups for backwards and forwards compatibility. That leaves the last 2 digit groups which often get referred to as major and minor versions. The first of the 3 digit groups has not changed in 20 years which means many scripts simply don’t check for that change. Many admins who write scripts that check for the OS version tend to rely on sw_vers -productVersion which would normally spit out a value such as 10.15.5. Right now, we have nothing more to go by then what is in the betas which I won’t discuss, but it’s my understanding that Apple does indeed intend to go by macOS 11 in the end. One of the questions that has come up in the MacAdmins Slack come up is whether macOS is really macOS 11 or macOS 10.16. Last week at WWDC 2020, Apple announced macOS 11 (Big Sur). ![]()
0 Comments
Leave a Reply. |