Add swift version file to record the Swift toolchain to use #8411
Conversation
…king with SwiftPM
cmcgee1024
requested review from
bnbarham,
MaxDesiatov,
jakepetroules,
xedin,
dschaefer2,
shawnhyam,
bripeticca,
plemarquand,
owenv,
bkhouri and
daveyc123
as code owners
|
@swift-ci please test |
|
@swift-ci please test |
| @@ -0,0 +1 @@ | |||
| 6.0.3 | |||
There was a problem hiding this comment.
This file is missing a trailing newline. Additionally, could it have a comment on the first or second line pointing to relevant documentation for discoverability?
There was a problem hiding this comment.
This file should be dead simple, able to be cat'ed as part of scripts/commands to easily get the desired toolchain without any further processing.
| 10. While creating your PR, make sure to follow the PR Template providing information about the motivation and highlighting the changes. | ||
| 11. Reviewers are going to be automatically added to your PR | ||
| 12. Pull requests will be merged by the maintainers after it passes CI testing and receives approval from one or more reviewers. Merge timing may be impacted by release schedule considerations. | ||
| 5. If a particular version of the Swift toolchain is needed then update the `.swift-version` file to that version (or use `swiftly use` to update it). |
There was a problem hiding this comment.
I don't think we should encourage contributors to bump the version requirement. It would misalign with the version used on CI then.
There was a problem hiding this comment.
I think that this would be a great discussion point in any PR that attempts to use features of a newer toolchain and pinpoint exactly what code changes require the newer version. Updating the swift version file reveals that, and someday the hope is that the CI would attempt to use that toolchain to verify the PR.
There was a problem hiding this comment.
From my opinion, the CIs pipelines should use the version of the toolchain specified in the .swift-version.
We should work on getting our current pipelines updated to install said version if a .swift-version files exists on the branch/PR being "built"
| 11. Reviewers are going to be automatically added to your PR | ||
| 12. Pull requests will be merged by the maintainers after it passes CI testing and receives approval from one or more reviewers. Merge timing may be impacted by release schedule considerations. | ||
| 5. If a particular version of the Swift toolchain is needed then update the `.swift-version` file to that version (or use `swiftly use` to update it). | ||
| 6. Try to keep your changes (when possible) below 200 lines of code. |
There was a problem hiding this comment.
| 6. Try to keep your changes (when possible) below 200 lines of code. | |
| 6. Try to keep your changes (when possible) below 200 lines of code. Split your change into multiple PRs when the diff exceeds this limit. |
There was a problem hiding this comment.
I'm hoping to keep this PR scoped to just the changes needed for tracking swift toolchain version. The only reason this PR changes this line is to renumber the ordered list to insert. I would have preferred to use the GitHub markdown auto-numbering feature.
Further editing of the contribution guide can be tracked in another PR.
| 5. If a particular version of the Swift toolchain is needed then update the `.swift-version` file to that version (or use `swiftly use` to update it). | ||
| 6. Try to keep your changes (when possible) below 200 lines of code. | ||
| 7. We use [SwiftFormat](https://github.com/nicklockwood/SwiftFormat) to enforce code style. Please install and run SwiftFormat before submitting your PR, ideally isolating formatting changes only to code changed for the original goal of the PR. This will keep the PR diff smaller. | ||
| 8. Commit (include the Radar link or GitHub issue id in the commit message if possible and a description your changes). Try to have only 1 commit in your PR (but, of course, if you add changes that can be helpful to be kept aside from the previous commit, make a new commit for them). |
There was a problem hiding this comment.
The last sentence here is not relevant, people can have as many commits (including merge commits) in their PRs as they please since we squash before merging anyway.
| 8. Commit (include the Radar link or GitHub issue id in the commit message if possible and a description your changes). Try to have only 1 commit in your PR (but, of course, if you add changes that can be helpful to be kept aside from the previous commit, make a new commit for them). | |
| 8. Commit (include the Radar link or GitHub issue id in the commit message if possible and a description your changes). |
There was a problem hiding this comment.
Same comment as above. Can we focus on the tracking of the swift toolchain version in this PR? I don't mind reviewing further refinements to the contribution guide separately.
| 2. Clone a working copy of your fork | ||
| 3. Create a new branch | ||
| 4. Make your code changes |
There was a problem hiding this comment.
Let's update punctuation in each point for consistency.
| 2. Clone a working copy of your fork | |
| 3. Create a new branch | |
| 4. Make your code changes | |
| 2. Clone a working copy of your fork. | |
| 3. Create a new branch. | |
| 4. Make your code changes. |
There was a problem hiding this comment.
Same comment as above.
| 9. Push the commit / branch to your fork | ||
| 10. Make a PR from your fork / branch to `apple: main` | ||
| 11. While creating your PR, make sure to follow the PR Template providing information about the motivation and highlighting the changes. | ||
| 12. Reviewers are going to be automatically added to your PR |
There was a problem hiding this comment.
nit: punctuation consistency
| 9. Push the commit / branch to your fork | |
| 10. Make a PR from your fork / branch to `apple: main` | |
| 11. While creating your PR, make sure to follow the PR Template providing information about the motivation and highlighting the changes. | |
| 12. Reviewers are going to be automatically added to your PR | |
| 9. Push the commit / branch to your fork. | |
| 10. Make a PR from your fork / branch to `apple:main`. | |
| 11. While creating your PR, make sure to follow the PR Template providing information about the motivation and highlighting the changes. | |
| 12. Reviewers are going to be automatically added to your PR. |
| 10. While creating your PR, make sure to follow the PR Template providing information about the motivation and highlighting the changes. | ||
| 11. Reviewers are going to be automatically added to your PR | ||
| 12. Pull requests will be merged by the maintainers after it passes CI testing and receives approval from one or more reviewers. Merge timing may be impacted by release schedule considerations. | ||
| 5. If a particular version of the Swift toolchain is needed then update the `.swift-version` file to that version (or use `swiftly use` to update it). |
There was a problem hiding this comment.
From my opinion, the CIs pipelines should use the version of the toolchain specified in the .swift-version.
We should work on getting our current pipelines updated to install said version if a .swift-version files exists on the branch/PR being "built"
|
@swift-ci test Windows |
When working with SwiftPM, there is a particular version that development is
expected to use so that all of the compilers, standard libraries, test frameworks,
etc. are expected to be working. The
.swift-versionfile establishes a standardway to record this information. Also, there is tooling available through
swiftlyto use that information to automatically use the correct toolchain in any git commit
to set the developer's toolchain when they run and test SwiftPM functions at desk.
Create the
.swift-versionfile and set it to the current expected toolchain versionfor development: 6.0.3. Add documentation regarding this file in the contributor guide.
Link to swiftly so that developers can install the tool, and enhance their development
workflows.