Description
There is no installed Xcode 12.1.0 version and instead the Xcode located at /Applications/Xcode_12.1.app is actually version 12.1.1. The version located at /Applications/Xcode_12.1.1.app is also 12.1.1.
An excerpt from a fastlane log:
INFO [2020-11-05 02:58:38.16]: $ defaults read /Applications/Xcode_12.1.app/Contents/Info.plist CFBundleShortVersionString
INFO [2020-11-05 02:58:39.05]: ▸ 12.1.1
INFO [2020-11-05 02:58:39.05]: $ defaults read /Applications/Xcode_12.1.1.app/Contents/Info.plist CFBundleShortVersionString
INFO [2020-11-05 02:58:39.10]: ▸ 12.1.1
Area for Triage:
Containers
Question, Bug, or Feature?:
Bug
Virtual environments affected
Expected behavior
Xcode 12.1.0 is available on the system and properly located at /Applications/Xcode_12.1.app.
Actual behavior
Xcode 12.1.0 is not available on the system and instead there are two versions of Xcode 12.1.1. One located at /Applications/Xcode_12.1.app and one located at /Applications/Xcode_12.1.1.app.
Repro steps
macos-10.15 action. defaults read /Applications/Xcode_12.1.app/Contents/Info.plist CFBundleShortVersionStringHello @zac , usually, we install the latest Xcode for every major.minor pair.
For example, when Xcode 12.0.1 is released, we replace 12.0.0 by 12.0.1 (except cases when it is beta release)
Changing of patch version (third number) doesn't bring breaking changes because of semantic versioning and RC means that most likely this version will be officially published as stable.
/Applications/Xcode_12.1.app is just symlink to the latest 12.1.x installed on image
Do you have any use-cases that are broken after this change?
Sorry for my misunderstanding!
I was doing the following using Fastlane:
xcversion(version: "= 12.1")
That uses xcode-install to switch to a given version of Xcode. This was working back when the exact version 12.1.0 was installed and fails now that it can't find that version. Obviously if I used xcode-select directly then this wouldn't be an issue since it takes a path, but since xcode-install uses spotlight to find Xcodes by version, it fails.
Not sure it is worth considering my use-case since I have a workaround and now know about the symlinking. Now I'm just doing:
xcversion(version: "~> 12.1.0")
I obviously love that you all are super on top of new Xcode versions, so I wouldn't want that to change! To me it seems a little risky to treat 12.1.1 RC (nee "GM seed") as a replacement for 12.1.0 since I personally don't consider a release 'official' until it drops the GM seed / RC designation. Since they've been known to release additional GM seeds as show stoppers are found, I've always waited for the App Store version. On the other hand, I totally get what you mean that it's just a patch.
In any case, thanks for your work on keeping all these images up-to-date! It's been great having access to betas very early in the cycle 👍
Thank you for additional information.
We will discuss it more internally and probably, it makes sense to keep previous patch version until the stable version is fully released. It is safer way for our customers. The main concern is that additional Xcode version increases image-generation / image-deployment time but it shouldn't a big deal to keep a few Xcode side by side for a few more weeks.
I am going to close this issue for now. Please let me know if you need any assistance
@maxim-lobanov version 12.1.1 is missing ios14.1 simulator and the CI is broken because it only has 14.2 simulators
this is still an issue, something is wrong here.
I agree with @sisoje, we need 12.1.0 back.
@marvhen , @sisoje , thank you for feedback guys, it definitely makes sense.
We are going to rollback the current image
cc: @miketimofeev
Reopened issue until rollback is finished
Current status
Almost all the environments are rolled back, others will be finished in the next few hours.
Rollback completed!
Most helpful comment
@marvhen , @sisoje , thank you for feedback guys, it definitely makes sense.
We are going to rollback the current image
cc: @miketimofeev