diff --git a/README.md b/README.md index eaaeff4c..005c8773 100644 --- a/README.md +++ b/README.md @@ -40,22 +40,3 @@ npm run package Packaged applications will automatically update if there is a newer version available (compared to build version in package.json), this does also apply to development versions (ending on -devXX), which are updated via a separate stream. Updates are distributed once the build version is changed and a tag has been added. - -## How to build a Release - -- Make sure all PRs for the release are merged to the `master` branch -- For minor releases create a new branch on the repo from master (e.g. `v.3.4`) -- In the new release branch on your local machine: - - Cherry Pick all commits from the `master` branch you want included in the release - - Update the version (several places) in `package.json` and `package-lock.json` - - Create a Release Candidate for testing: - - Add a new tag with the version number (e.g. `v3.4.4-rc.1`) - - Push the commits and tag to the repo - - The CI will build the release candidate (because of the tag) and add it to the GitHub releases - - Test the release candidate - - If the release candidate is good - - Update the version (several places) in `package.json` and `package-lock.json` - - Create a new tag with the version number (e.g. `v3.4.4`) - - Push the commits and tag to the repo - - The CI will build the release and add it to the GitHub releases -- Bump the version in the `master` branch to the next version (e.g. `3.4.5-dev.1`) diff --git a/docs/release-docs.md b/docs/release-docs.md new file mode 100644 index 00000000..c24ba75d --- /dev/null +++ b/docs/release-docs.md @@ -0,0 +1,20 @@ +# How to build a Release + +Only relevant to repository maintainers. + +- Make sure all PRs for the release are merged to the `master` branch +- For minor releases create a new branch on the repo from master (e.g. `v.3.4`) +- In the new release branch on your local machine: + - Cherry Pick all commits from the `master` branch you want included in the release + - Update the version (several places) in `package.json` and `package-lock.json` + - Create a Release Candidate for testing: + - Add a new tag with the version number (e.g. `v3.4.4-rc.1`) + - Push the commits and tag to the repo + - The CI will build the release candidate (because of the tag) and add it to the GitHub releases + - Test the release candidate + - If the release candidate is good + - Update the version (several places) in `package.json` and `package-lock.json` + - Create a new tag with the version number (e.g. `v3.4.4`) + - Push the commits and tag to the repo + - The CI will build the release and add it to the GitHub releases +- Bump the version in the `master` branch to the next version (e.g. `3.4.5-dev.1`)