<div dir="ltr">Yeah, my money is on 11.X being the 11.X SDK since that is typically the pattern with iOS.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 18, 2020 at 10:21 PM Chris Jones <<a href="mailto:jonesc@hep.phy.cam.ac.uk">jonesc@hep.phy.cam.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 19 Nov 2020, at 3:07 am, Ryan Schmidt <<a href="mailto:ryandesign@macports.org" target="_blank">ryandesign@macports.org</a>> wrote:<br>
> <br>
> <br>
> <br>
>> On Nov 18, 2020, at 21:04, Chris Jones wrote:<br>
>> <br>
>> On 19 Nov 2020, at 2:31 am, Ryan Schmidt wrote:<br>
>> <br>
>>>> On Nov 18, 2020, at 20:28, Saagar Jha wrote:<br>
>>>> <br>
>>>>> On Nov 18, 2020, at 18:12, Ryan Schmidt wrote:<br>
>>>>> <br>
>>>>> Based on the fact that Apple has released a beta of macOS Big Sur 11.1 already, we can now see that Big Sur should be referred to as version 11, not 11.0 (and it would be reasonable to expect that next year's macOS will be version 12).<br>
>>>>> <br>
>>>>> If you are fixing any ports that had been coded to assume the macOS version was always 10.x, be sure that you're not fixing it to simply accept versions 10.x or 11.x. Instead, remove any assumption about the version number so that you won't have to revisit the problem again every year.<br>
>>>>> <br>
>>>>> When Josh released MacPorts 2.6.4 recently, he used the number 11.0 on the Big Sur installer package. For the next version, we should use the version number 11 to denote Big Sur.<br>
>>>>> <br>
>>>>> I did the same when naming the Big Sur buildbot machines and will change them from 11.0 to 11 soon.<br>
>>>>> <br>
>>>>> Part of our decision to use "11.0" came from the way that Apple named the SDK: MacOSX11.0.sdk. We will have to see if they change this to MacOSX11.1.sdk in a future version of Xcode and the CLT. If they do, that would represent a change from their previous strategy, and it would be a problem for MacPorts because the SDK path gets baked into some ports. Previously this was ok since the SDK path would stay the same for the life of the OS version, but if it now changes during the life of the OS we may find ourselves needing to rebuild some ports to update their SDK paths.<br>
>>>>> <br>
>>>>> We may also need to adjust how MacPorts selects the SDK version and SDK path, depending on whether Apple changes the SDK name.<br>
>>>>> <br>
>>>> <br>
>>> <br>
>>>> The macOS SDK in Xcode 11.3 is MacOSX11.1.sdk.<br>
>>> <br>
>>> Presumably you mean Xcode 12.3.<br>
>>> <br>
>>> But ok, then this will suck, and users on Big Sur will need to make sure that they use an Xcode version that has the right SDK for their *minor* OS version.<br>
>> <br>
>> Maybe macports should move away from using the versioned  sdk and just use the versionless link instead, which should also be present...<br>
> <br>
> MacPorts should be falling back to MacOSX.sdk if the versioned one is not available:<br>
> <br>
> <a href="https://github.com/macports/macports-base/commit/73ee4b496ffb35ae8c57606580c8b2e7cd440b34" rel="noreferrer" target="_blank">https://github.com/macports/macports-base/commit/73ee4b496ffb35ae8c57606580c8b2e7cd440b34</a><br>
> <br>
> However we would rather use the versioned one to be sure it's the right version. Software written specifically for Macs may be able to deal with a newer-than-OS-version SDK, but most software in MacPorts isn't written specifically for Macs and can't always cope with that.<br>
<br>
I guess we will have to wait and see how much of a pain the sdk version changing each minor os update, if thats what is indeed going to happen, will be, and then decide whats the lesser evil here..<br>
> <br>
<br>
</blockquote></div>