From f327aaaa91b507b36e75b66f012048dab13f2307 Mon Sep 17 00:00:00 2001 From: Zach Wasserman Date: Mon, 8 Nov 2021 18:17:42 -0800 Subject: [PATCH] Update documentation for patch releases (#2652) --- docs/03-Contributing/05-Releasing-Fleet.md | 64 +++++++++++++++++++++- 1 file changed, 63 insertions(+), 1 deletion(-) diff --git a/docs/03-Contributing/05-Releasing-Fleet.md b/docs/03-Contributing/05-Releasing-Fleet.md index d8fc6f87de..7dc92494a5 100644 --- a/docs/03-Contributing/05-Releasing-Fleet.md +++ b/docs/03-Contributing/05-Releasing-Fleet.md @@ -46,7 +46,7 @@ When the Actions Workflow has completed: ### Upgrading -Please visit our [update guide](https://github.com/fleetdm/fleet/blob/main/docs/01-Using-Fleet/08-Updating-Fleet.md) for upgrade instructions. +Please visit our [update guide](https://fleetdm.com/docs/using-fleet/updating-fleet) for upgrade instructions. ### Documentation @@ -77,3 +77,65 @@ When editing is complete, publish the release. permissions, so typically this announcement will be done by `@zwass`. Announce the release via blog post (on Medium) and Twitter (linking to blog post). + +## Patch releases + +Generally, a patch should be released when bugs or performance issues are identified that prevent +users from getting their job done with Fleet. + +### Process + +#### The easy way + +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. + +#### The hard way + +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: + +1. Create the new branch, starting from the git tag of the prior release. Patch branches should be + prefixed with `patch-`. In this example we are creating `4.3.1`: + + ``` + git checkout fleet-v4.3.0 + git checkout --branch patch-fleet-v4.3.1 + ``` + +2. Cherry pick the necessary commits into the new branch: + + ``` + git cherry-pick d34db33f + ``` + +3. Push the branch to github.com/fleetdm/fleet: + + ``` + git push origin patch-fleet-v4.3.1 + ``` + + When a `patch-*` branch is pushed, the [Docker publish + Action](https://github.com/fleetdm/fleet/actions/workflows/goreleaser-snapshot-fleet.yaml) will + be invoked to push a container image for QA with `fleetctl preview` (eg. `fleetctl preview + --tag patch-fleet-v4.3.1`). + +4. Check in the GitHub UI that Actions ran successfully for this branch and perform [QA smoke + testing](../../.github/ISSUE_TEMPLATE/smoke-tests.md). + +5. 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. + +6. Cherry-pick the commit containing the changelog updates into a new branch, and merge that commit + into `main` through a Pull Request. + +7. **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](https://github.com/fleetdm/fleet/issues/2850): Improve docs/tooling for this. \ No newline at end of file