actions
/
toolkit
mirror of https://github.com/actions/toolkit
1
0
Fork 0
Code

Fix some typos (#200)

pull/201/head
Josh Gross 2019-11-03 14:32:46 -05:00 committed by Bryan MacFarlane
parent 626bbe7136
commit 46c2a7e41a
1 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
docs/action-versioning.md
View File

@ -1,6 +1,6 @@
# Versioning
Actions are downloaded and run from the GitHub graph of repos. The workflow references an action use a ref.
Actions are downloaded and run from the GitHub graph of repos. The workflow references an action using a ref.
Examples:
@ -15,24 +15,24 @@ steps:
Binding to a major version is the latest of that major version ( e.g. `v1` == "1.*" )
Major versions should guarentee compatibility. A major version can add net new capabilities but should not break existing input compatibility or break existing workflows.
Major versions should guarantee compatibility. A major version can add net new capabilities but should not break existing input compatibility or break existing workflows.
Major version binding allows you to take advantage of bug fixes and critical functionality and security fixes. The `master` branch has latest code and is unstable to bind to since a breaking new major version may first get implemented in master.
Major version binding allows you to take advantage of bug fixes and critical functionality and security fixes. The `master` branch has the latest code and is unstable to bind to since a breaking new major version may first get implemented in master.
> Warning: do not reference `master` since that is latest code and can be carrying breaking changes of the next major version.
> Warning: do not reference `master` since that is the latest code and can be carrying breaking changes of the next major version.
```yaml
steps:
- uses: actions/javascript-action@master # do not do this
```
Binding to the immutable sha1 may offer more reliability. However, note that the hosted images toolsets (e.g. ubuntu-latest) move forward and if there is a tool breaking issue, actions may react with a patch to a major version to compensate so binding to a specific sha may prevent you from getting fixes.
Binding to the immutable sha1 may offer more reliability. However, note that the hosted images toolsets (e.g. ubuntu-latest) move forward and if there is a tool breaking issue, actions may react with a patch to a major version to compensate so binding to a specific SHA may prevent you from getting fixes.
> Recommendation: bind to major versions to get functionality and fixes but reserve binding to a specific release or sha as a mitigation strategy for unforseen breaks.
> Recommendation: bind to major versions to get functionality and fixes but reserve binding to a specific release or SHA as a mitigation strategy for unforeseen breaks.
# Recommendations
1. **Create a release branch for each major version**: For example, `releases\v1`. This will allow for releases of that major major while development of a different major version proceeds.
1. **Create a release branch for each major version**: For example, `releases\v1`. This will allow for releases of that major version while the development of a different major version proceeds.
2. **Validate changes referencing the release branch**:
@ -41,7 +41,7 @@ steps:
- uses: actions/sample-action@releases/v1
```
3. **Create a GitHub release for each specific version**: Creating a release like [ v1.0.0 ](https://github.com/actions/javascript-action/releases/tag/v1.0.0) allows users to bind back to a specific version if an issue is encoutered with the latest major version.
3. **Create a GitHub release for each specific version**: Creating a release like [ v1.0.0 ](https://github.com/actions/javascript-action/releases/tag/v1.0.0) allows users to bind back to a specific version if an issue is encountered with the latest major version.
4. **Release that version by updating the major version tag**: Move the major version tag (v1, v2, etc.) to point to the ref of the current release. This will act as the stable release for that major version. You should keep this tag updated to the most recent stable minor/patch release.
@ -51,7 +51,7 @@ git tag -fa v1 -m "Update v1 tag"
git push origin v1 --force
```
This will results in a major version tag and the latest specific version pointing to the same sha. See [javascript-action tags](https://github.com/actions/javascript-action/tags) as an example.
This will result in a major version tag and the latest specific version pointing to the same SHA. See [javascript-action tags](https://github.com/actions/javascript-action/tags) as an example.
5. **Compatibility Breaks**: introduce a new major version branch (releases/v2) and tag (v2) if changes will break existing workflows. For example, changing inputs.