-
Notifications
You must be signed in to change notification settings - Fork 153
Add documentation for the .xcode-version
file
#218
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Xcode follows what was on fastlane implementation around beta's. It currently doesn't handle Release Candidates.
XCODE_VERSION.md
Outdated
``` | ||
|
||
```txt | ||
14.0 Beta 6 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Xcodes followed how it was laid out in Xcodes followed how it was laid out on fastlane https://github.com/fastlane/ci/blob/master/docs/xcode-version.md so these are 14.0b6
Not sure if going forward that is the best solution, but for consistency we should keep it like that. Some examples are on the tests - https://github.com/RobotsAndPencils/xcodes/blob/main/Tests/XcodesKitTests/Version%2BGemTests.swift
https://github.com/RobotsAndPencils/xcodes/blob/main/Sources/XcodesKit/Version%2BGem.swift
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ooh. Interesting! This makes sense.
Maybe this should be made more explicit to users, perhaps? For instance, when printing xcodes list
, we see this:
[…]
13.0 Beta (13A5154h)
13.0 Beta 2 (13A5155e)
13.0 Beta 3 (13A5192i)
13.0 Beta 3 (13A5192j)
13.0 Beta 4 (13A5201i)
13.0 Beta 5 (13A5212g)
13.0 (13A233)
13.1 (13A1030d)
13.2 Beta (13C5066c)
13.2 Beta 2 (13C5081f)
13.2 (13C90)
13.2.1 (13C100)
13.3 Beta (13E5086k)
13.3 Beta 2 (13E5095k)
13.3 Beta 3 (13E5104i)
13.3 (13E113)
13.3.1 (13E500a)
13.4 (13F17a)
13.4.1 (13F100) (Installed)
14.0 Beta (14A5228q)
14.0 Beta 2 (14A5229c)
14.0 Beta 3 (14A5270f)
14.0 Beta 4 (14A5284g)
14.0 Beta 5 (14A5294e)
14.0 Beta 6 (14A5294g)
14.0 (14A309) (Installed, Selected)
14.1 Beta (14B5024h) (Installed)
14.0.1 Release Candidate (14A400)
So it's not clear how one should guess what the identifier for those betas and RCs should be, if they are not aware of that rule (e.g. "14.1b1"), what do you think?
Of course, this ☝️ is unrelated to this PR, and I can update this PR to reflect the current logic, but just some food for thought for another future improvement :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm I see in the README that it does support e.g. "Beta 6" when passing the version as an argument: https://github.com/RobotsAndPencils/xcodes/blob/93dcc92f8f1cb64b91f831f84a5567d8149498de/README.md?plain=1#L67
So the parsing of the version from CLI argument and .xcode-version
is actually different? Can they be made the same/consistent, or was there a reason for it to be implemented like this?
Because apparently that one can also handle GM identifiers (which the docs you posted above indicate this one doesn't: https://github.com/RobotsAndPencils/xcodes/blob/93dcc92f8f1cb64b91f831f84a5567d8149498de/Sources/XcodesKit/Version%2BGem.swift#L14
and it would then also behave in a more user-friendly way because users could type out in their .xcode-version files what they see in xcodes list
(as I mentioned above), what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rogerluan Guess I don't know enough about the history of .xcode-version. I'm all for standards, but Xcodes uses a Xcode naming convention I think that is unique to us. We took the xcinstalls' beta form (and GM at the time) so that both could use the same version.
If that is ok to change (use 11.0 Beta 2
over 11.0b2
i'm all for it. But you're right we can have another PR later for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aah got it! Backwards compatibility, you're right!
We could either:
- Maintain both ways and mark one as deprecated (even log warnings when we detect the deprecated formatting)
- Drop the current way and bump to v2.0.0 (major bump due to breaking changes)
If we opt for the first one, it could be finally removed when we decide to release v2.0.0 at any given point in the future, but it would mean we'd have to maintain 2 ways of doing things until then.
WDYT?
|
||
```txt | ||
12.1 GM | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
```txt | |
12.1 GM | |
``` |
Co-authored-by: Roger Oba <rogerluan.oba@gmail.com>
This document was largely copied by the now-archived fastlane.ci repository: https://github.com/fastlane/ci/blob/master/docs/xcode-version.md and also based on xcpretty/xcode-install#424 where I added the same file: https://github.com/xcpretty/xcode-install/blob/master/XCODE_VERSION.md
I updated the language and references to xcode-install to
xcodes
.I believe we should still try and make this a standard in the iOS community, hence why I'm creating this PR, to give a bit more life and exposure to this great feature.
It's amazing to see that xcodes already support it 💪 Great job!