Elgato_dark/fleet
1
0
Fork 0
mirror of https://github.com/fleetdm/fleet synced 2026-05-24 09:28:54 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 52

Update documentation for patch releases (#2652)

Browse source
This commit is contained in:
Zach Wasserman 2021-11-08 18:17:42 -08:00 committed by GitHub
parent ce56f81130
commit f327aaaa91
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 63 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

64
docs/03-Contributing/05-Releasing-Fleet.md
View file

@ -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.