-
-
Notifications
You must be signed in to change notification settings - Fork 6.7k
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
[swift5] update new minimum OS supported versions #13667
[swift5] update new minimum OS supported versions #13667
Conversation
{{#useAlamofire}} | ||
s.dependency 'Alamofire', '~> 5.4.3' | ||
s.dependency 'Alamofire', '~> 5.6.2' |
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.
I wonder whether we could be a bit less restrictive here and only pin major versions instead of major and minor version. With ~> 5.6.2
we only allow 5.6.2 and all following patch updates for it. This might not be a problem if there is no other dependency to Alamofire in a project but otherwise a project could never resolve Alamofire 5.7+ versions and is forced to stay on minor version 5.6* until generator is updated again. As Alamofire version policy is also based on semantic versioning this might be ok I think. Just a thought that crossed my mind
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.
Hey, I agree with you.
Do you suggest keeping the 5.4.3?
Or update it?
Thanks
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.
Hey. I would probably still allow the lower AF versions as I know some dependencies still require 5.4*. That's why my suggestion would be to use ~> 5.4
modifier to not break dependency resolution for those.
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.
Done 👍
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.
~> 5.4.0
will only allow up to the next minor version, so e.g. AF 5.5.0 would already not be possible to resolve anymore. I think in order to support everything from 5.4.0 until (and not including) the next major version we would need to use ~> 5.4
instead. Then we would also allow 5.5.x, 5.6.y and so on
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.
What about now?
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.
CI is failing... Maybe I will try to revert the dependencies changes and save that for another PR
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.
Yes agree its probably better to do this in a separate PR
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.
@Jonas1893 thanks for helping review this PR. If you want to help review more Swift Cliente PRs are you welcome 👍
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.
Hey @4brunu thx will gladly do so :)
CI failure is not related to this PR.
|
With Xcode 14, the minimum OS supported versions changed and some OS versions are not supported anymore.
The new minimum OS supported versions by Xcode 14 are:
https://developer.apple.com/documentation/xcode-release-notes/xcode-14-release-notes
So with this update, those are the new minimum OS supported versions in the Swift generator
PR checklist
This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
These must match the expectations made by your contribution.
You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example
./bin/generate-samples.sh bin/configs/java*
.For Windows users, please run the script in Git BASH.
master
(6.1.0) (minor release - breaking changes with fallbacks),7.0.x
(breaking changes without fallbacks)@jgavris (2017/07) @ehyche (2017/08) @Edubits (2017/09) @jaz-ah (2017/09) @4brunu (2019/11)