https://github.com/mearns/set-build-version
A github action for setting an appropriate package.json version string for your build.
https://github.com/mearns/set-build-version
Last synced: about 1 month ago
JSON representation
A github action for setting an appropriate package.json version string for your build.
- Host: GitHub
- URL: https://github.com/mearns/set-build-version
- Owner: mearns
- License: mit
- Created: 2020-11-21T01:07:14.000Z (over 4 years ago)
- Default Branch: master
- Last Pushed: 2020-12-22T22:08:32.000Z (over 4 years ago)
- Last Synced: 2024-04-23T18:39:51.250Z (about 1 year ago)
- Language: JavaScript
- Size: 104 KB
- Stars: 0
- Watchers: 2
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# set-build-version
This is currently the only versioning supported:
1. Master branch is built as a "beta" version, using the next patch version above what is specified in package.json.
The version number takes the form 1.2.3-alpha.$buildId. Package.json should include "dev" as a component in the pre-release
version component, or an error is generated, failing the build. The "dev" component is replaced with the pair of "alpha.$buildId"
components. Any other pre-release components are kept.
2. Non-master branches are built as "alpha" versions, using the next patch version above what is specified in package.json.
The version number takes the form 1.2.3-beta.branch-$branchSlug.$buildId. Package.json should include "dev" as a component in the pre-release
version component, or an error is generated, failing the build. The "dev" component is replaced with the triplet of "beta.branch-$branchSlug.$buildId"
components. Any other pre-release components are kept.
Typical work flow is:
1. Create a new branch for each work item. If there is an issue or other ticket for the work item, the branch name would be of the form
"ticket/\${id}" with an optional short identifier like "ticket/123-fix-timeouts".
2. Once your work is ready to promote, get it merged into master. This merge should include an appropriate change to the version number. If
there is a conflict with the change to the version number, it likely indicates a conflict in the code as well.
3. When master is ready to release, merge it into the "release" branch, make one more commit on that branch with the correct version string,
(i.e., remove the "-dev" pre-release component) and push it. The github actions pipeline for the "release" branch will run the build and
verification on it, then create a tag for it, and publish it.
## Publishing From Branches
Release versions should be published from the "release" branch. This should only include releases and release-candidates, i.e., no pre-release
component of the version string, or a pre-release component that starts with an "RC" element, followed by a numeric element.
If you want to publish from other branches, you can configure branch name patterns to publish from.