mirror of
https://github.com/fleetdm/fleet
synced 2026-05-23 17:08:53 +00:00
Update README.md (#19991)
Give better instructions to fix and check for patch readiness that matches what we do today. --------- Co-authored-by: Martin Angers <martin.n.angers@gmail.com>
This commit is contained in:
parent
bc6fc85113
commit
c0d8e1f99e
1 changed files with 3 additions and 1 deletions
|
|
@ -45,9 +45,11 @@ If there are no product changes, and the DRI decides to prioritize the story, th
|
|||
> We prefer the term engineering-initiated stories over technical debt because the user story format helps keep us focused on our users and contributors.
|
||||
|
||||
### Fix a bug
|
||||
|
||||
All bug fix pull requests should have a mention back to the issue they resolve with #<ticket_number> in the description or even in a comment. Please do not use any [automated words](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) since we don't want the tickets auto-closing when PR's are merged.
|
||||
If the bug is labeled `~unreleased bug`, branch off and put your PR into `main`. These issues can be closed as soon as they complete QA.
|
||||
|
||||
If the bug is labeled `~released bug`, branch off the tag for the latest release of Fleet and put your PR into `main`. For example, `git checkout fleet-v4.48.2`, then `git checkout -b my-bug-fix-branch`. These issues are not closed until the next release of Fleet. This approach makes sure the bug fix is not built on top of unreleased feature code, which can cause merge conflicts during patch releases.
|
||||
If the bug is labeled `~released bug`, branch off and put your PR into `main`. After merging checkout the latest tag, for example `git checkout fleet-v4.48.2`, then `git fetch; git cherry-pick <commit>`. If the cherry-pick fails with a conflict call out in the ticket how to resolve or if it is sufficiently complicated call out this fix is not suited for the patch release process and should only be included in the end of sprint release. This approach makes sure the bug fix is not built on top of unreleased feature code, which can cause merge conflicts during patch releases.
|
||||
|
||||
### Begin a merge freeze
|
||||
To ensure release quality, Fleet has a freeze period for testing beginning the Tuesday before the release at 11:00 AM Pacific. Effective at the start of the freeze period, new feature work will not be merged into `main`.
|
||||
|
|
|
|||
Loading…
Reference in a new issue