Serverless Framework relies on semantic commit messages which allows to streamline the release process (versioning and changelog generation is automated)
See proposed Commit Message Guidelines
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 a single semantic commit message.
PR's comming from branches have commit messages validated with commmitlint
Releases are triggered manually by preparing a release PRs
Contain new features, enhancements and non-critical bug fixes. Issued every two weeks
-
Create the
release
branch (should derive from currentmaster
state) -
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 apackage.json
is^2.2.4
then it should be updated to^2.3.5
)
Note: Unfortunately there seems no reliable utility to automate that (there's a request atnpm-check-updates
)
If you handle installation of dependencies through npm-cross-link then--bump-deps
option will bump version ranges as expected -
Commit eventual dependency version updates with following commit message:
chore: Bump dependencies
-
Run
npm run prepare-release
command.
It'll automatically bump version inpackage.json
to expected one (by inspecting changes since previous release) and will generate new changelog entry. -
Improve generated changelog entry in
CHANGELOG.md
:- Ensure to remove evenutal items that were already published with patch releases
- Improve formatting and messages if applicable
- Ensure that updated
CHANGELOG.md
follows prettier formatting
-
Commit
package.json
andCHANGELOG.md
changes with following commit message:chore: Release
Note: For automation purpose it is important that it's the last commit in the PR -
Push branch upstream and create a PR.
Release PR's are automatically detected in CI by fact ofversion
inpackage.json
file being changed in last commit. In context of that build, existence of new version changelog entry (inCHANGELOG.md
) is validated. -
After PR is accepted by CI and one of the reviewers, merge it via "Rebase and merge" option
Further actions are automated in CI context:
master
CI build detects that release PR was merged (by fact that it covers change ofversion
field inpackage.json
file). Having that (after successufl tests pass) version tag is created and pushed to the repository.- Tag CI build publishes new version to npm, also it retrieves release notes from CHANGELOG.md and publishes them to GitHub.
Usually about important bug-fixes or features that we wish to release immediately.
Contrary to regular releases, they derive from release-fast-track
branch (not master
).
release-fast-track
branch is automatically updated to point released version right after it's published, that means that if release is held from master
, the release-fast-track
history is rewritten.
For that reason community PR's in all cases should be based against master
. If we want to fast release a patch as proposed by a community. After it is merged into master
, we need to cherry-pick it into a branch that derives from release-fast-track
and prepare a release on top of that.
-
Ensure that PR which contains a fix intended to be immediately published, derives from
release-fast-track
branch and is based against it. -
Run
npm run prepare-release
command in context pf a PR branch It'll automatically bump version inpackage.json
to expected one (by inspecting changes since previous release) and will generate new changelog entry. -
Improve generated changelog entry in
CHANGELOG.md
:- Improve formatting and messages if applicable
- If any updates were applied ensure that updated
CHANGELOG.md
follows prettier formatting
-
Commit
package.json
andCHANGELOG.md
changes with following commit message:chore: Release
Note: For automation purpose it is important that it's the last commit in the PR -
After PR is accepted by CI and one of the reviewers, merge it via "Rebase and merge" option
Further actions are automated in CI context:
release-fast-track
CI build detects that release PR was merged (by fact that it covers change ofversion
field inpackage.json
file). Having that (after successful tests pass) version tag is created and pushed to the repository.- Tag CI build, publishes new version to npm, also it retrieves release notes from CHANGELOG.md and publishes them to GitHub.
Improvements to release notes can be done at anytime to any already published version:
- Update
CHANGELOG.md
with desired changes (ensure they'd also end inmaster
) - Push updated release notes to GitHub by running:
npx github-release-from-cc-changelog <version>