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

Update versioning guidance (#40) 

* Update versioning guidance

* Missing step
pull/41/head
Danny McCormick 2019-08-06 08:17:49 -04:00 committed by GitHub
parent fc9958ec6a
commit da76d1fd39
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 20 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
docs/action-versioning.md
View File

@ -19,11 +19,25 @@ Binding to master is convenient but if a new major version is released which bre
# Recommendations # Recommendations
1. **Create a release**: use sematic versioning for the release (v1.0.9) 1. **Don't check node_modules into master**: This will discourage people from attaching to master since the action will fail. You can enforce this by including `node_modules` in your `.gitignore` file.
2. **Update the major version tag**: move the major version tag (v1, v2, etc.) to point to the ref of the current release. 2. **Create a release branch for each major version**: This will act as an alpha release for that major version. Any time you are ready to publish a new version from master, you should pull those changes into this branch (following the same steps listed below).
3. **Compaitbility Breaks**: introduce a new major version tag (v2) if changes will break existing workflows. For example, changing inputs. ```
git checkout -b releases/v1 # If this branch already exists, omit the -b flag
rm -rf node_modules
sed -i '/node_modules/d' .gitignore # Bash command that removes node_modules from .gitignore
npm install --production
git add node_modules .gitignore
git commit -m node_modules
git push origin releases/v1
```
3. **When ready for a stable release, add a 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.
```
git checkout releases/v1
git push origin :refs/tags/v1
git tag -fa v1 -m "Update v1 tag"
git push origin v1
```
4. **Create releases for minor and patch version updates**: From the GitHub UI create a release for each minor or patch version update titled with that release version (e.g. v1.2.3).
5. **Compaitbility Breaks**: introduce a new major version branch (releases/v2) and tag (v2) if changes will break existing workflows. For example, changing inputs.
See [Git-Basics-Tagging](https://git-scm.com/book/en/v2/Git-Basics-Tagging) See [Git-Basics-Tagging](https://git-scm.com/book/en/v2/Git-Basics-Tagging)