Note: Please prefix versions with
fleet-v4.0.0) in git tags, Helm charts, and NPM configs.
make changelogto pull the changes files into
CHANGELOG.md, then manually edit. When editing, order the most relevant/important changes at the time, and try to make the tone and syntax of the written language match throughout.
make changelogwill stage all changes file entries for deletion with the commit.
Commit these changes via Pull Request and pull the changes on the
main branch locally. Check that
HEAD of the
main branch points to the commit with these changes.
git tag fleet-v<VERSION> git push origin fleet-v<VERSION>
origin may be
upstream depending on your
git remote configuration. The intent here
is to push the new tag to the
GitHub Actions will automatically begin building the new release after the tag is pushed.
Wait while GitHub Actions creates and uploads the artifacts...
When the Actions Workflow has completed:
### Changes <COPY FROM CHANGELOG> ### Upgrading Please visit our [update guide](https://fleetdm.com/docs/using-fleet/updating-fleet) for upgrade instructions. ### Documentation Documentation for this release can be found at https://github.com/fleetdm/fleet/blob/<VERSION>/docs/README.md ### Binary Checksum **SHA256** ``` <COPY FROM checksums.txt> ```
When editing is complete, publish the release.
fleetctlon NPM. Run
npm publishin the fleetctl-npm directory. Note that NPM does not allow replacing a package without creating a new version number. Take care to get things correct before running
If releasing a "prerelease" of Fleet, run
npm publish --tag prerelease. This way, you can publish a prerelease of fleetctl while the most recent fleetctl npm package, available for public download, is still the latest official release.
@hererequires admin permissions, so typically this announcement will be done by
Announce the release via blog post (on Medium) and Twitter (linking to blog post).
Generally, a patch should be released when bugs or performance issues are identified that prevent users from getting their job done with Fleet.
If all commits on
main are acceptable for a patch (no high-risk changes, new features, etc.), then
the process is easy. Just follow the regular release process as described above, incrementing
only the patch (
major.minor.patch) of the version number. In this scenario, there is no need to
perform any of the steps below.
When only some of the newer changes in
main are acceptable for release, a separate patch branch
must be created and relevant changes cherry-picked onto that branch:
Create the new branch, starting from the git tag of the prior release. Patch branches should be
patch-. In this example we are creating
git checkout fleet-v4.3.0 git checkout --branch patch-fleet-v4.3.1
Cherry pick the necessary commits into the new branch:
git cherry-pick d34db33f
Push the branch to github.com/fleetdm/fleet:
git push origin patch-fleet-v4.3.1
patch-* branch is pushed, the Docker publish
be invoked to push a container image for QA with
fleetctl preview (eg.
Check in the GitHub UI that Actions ran successfully for this branch and perform QA smoke testing.
Follow the standard release instructions at the top of this document. Be sure that modifications
to the changelog and config files are commited on the
patch-* branch. When the patch has been
released, return to finish the following steps.
Cherry-pick the commit containing the changelog updates into a new branch, and merge that commit
main through a Pull Request.
Important! Manually check the database migrations. Any migrations that are not cherry-picked in a patch must have a higher timestamp than migrations that were cherry-picked. If there are new migrations that were not cherry-picked, verify that those migrations have higher timestamps. If they do not, submit a new Pull Request to increase the timestamps and ensure that migrations are run in the appropriate order.
TODO #2850: Improve docs/tooling for this.
If you notice something we’ve missed, or that could be improved, please click here to edit this page.