|
| 1 | +# Release process |
| 2 | + |
| 3 | +## Semi-automation |
| 4 | + |
| 5 | +This project relies on [semantic commit messages](https://www.conventionalcommits.org/en/v1.0.0-beta.4/#summary) which allows to streamline the release process (versioning and changelog generation is automated) |
| 6 | + |
| 7 | +See proposed [Commit Message Guidelines](https://docs.google.com/document/d/1hKUs3qt_aVp_PBI1UqvfaIqKma3jAJimEoGCRGGbOqs/edit#) |
| 8 | + |
| 9 | +In PR's as coming from forks (community contributions) while its welcome, we do not require to follow semantic commit messages. Yet, such PR is expected to be squash merged by project member with single semantic commit message. |
| 10 | + |
| 11 | +PR's comming from branches have commit messages validated with [commmitlint](https://commitlint.js.org/#/) |
| 12 | + |
| 13 | +## Release flow |
| 14 | + |
| 15 | +Releases are triggered manually by preparing a release PR's as follows |
| 16 | + |
| 17 | +1. Create a `release` branch (should derive from current `master` state) |
| 18 | +2. Bump version ranges of _all_ dependencies to latest supported versions (e.g. if latest version of a dependency is `2.3.5` and range in a `package.json` is `^2.2.4` then it should be updated to `^2.3.5`) |
| 19 | + _Note: Unfortunately there seems no reliable utility to automate that (there's a [request at `npm-check-updates`](https://github.com/tjunnone/npm-check-updates/issues/581)) |
| 20 | + If you handle installation of dependencies through [npm-cross-link](https://github.com/medikoo/npm-cross-link#npm-cross-link) then [`--bump-deps`](https://github.com/medikoo/npm-cross-link#general-options) option will bump version ranges as expected_ |
| 21 | +3. Commit eventual dependency version updates with following commit message: |
| 22 | + `chore: Bump dependencies` |
| 23 | +4. Run `npm run prepare-release` command. |
| 24 | + _It'll automatically bump version in `package.json` to expected one (by inspecting changes since previous release) and will generate new changelog entry._ |
| 25 | +5. If needed improve generated changelog entry in `CHANGELOG.md` |
| 26 | +6. Commit `package.json` and `CHANGELOG.md` changes with following commit message: |
| 27 | + `chore: Release` |
| 28 | + **Note: For automation purpose it is important that it's the last commit in the PR** |
| 29 | +7. Push branch upstream and create a PR. |
| 30 | + _Release PR's are automatically detected in CI by fact of `version` in `package.json` file being changed in last commit. In context of that build, existence of new version changelog entry (in `CHANGELOG.md`) is validated._ |
| 31 | +8. After PR is accepted by CI and one of the reviewers, merge it via _"Rebase and merge"_ option |
| 32 | + |
| 33 | +Further actions are automated in CI context: |
| 34 | + |
| 35 | +8. `master` CI build detects that release PR was merged (by fact that it covers change of `version` field in `package.json` file). Having that (after successufl tests pass) version tag is created and pushed to the repository. |
| 36 | +9. _tag_ CI build, publishes new version to npm, also it retrieves release notes from CHANGELOG.md and publishes them to GitHub. |
| 37 | + |
| 38 | +### Updating release notes for already published versions |
| 39 | + |
| 40 | +Improvements to release notes can be done at anytime to any already published version: |
| 41 | + |
| 42 | +1. Update `CHANGELOG.md` with desired changes (ensure they'd also end in `master`) |
| 43 | +2. Push updated release notes to GitHub by running: |
| 44 | + `npx github-release-from-cc-changelog <version>` |
0 commit comments