doc(bh-rfc-1): create initial draft rfc for release process #1089
+170
−0
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ddlees
force-pushed
the
bh-rfc-1
branch
5 times, most recently
from
4879833 to
40e69ca
Compare
urangel
reviewed
Feb 5, 2025
|
|
||
| - Feature branches are short-lived branches used to develop/enhance product features and fix bugs/defects. | ||
| - Feature branches are named by combining the project management issue number and an optional, short, human-readable, and hyphenated description of the work. | ||
| - E.g. - For issue number `bed-1234` the feature branch name could be either `bed-1234` or `bed-1234-my-short-description`. |
There was a problem hiding this comment.
I don't normally use the style myself but tend to see a double hyphen after the ticket number as in bed-1234--my-short-description instead of bed-1234-my-short-description. It doesn't seem to have much consequence but I figured I'd mention since one of the stated main goals of the document is to standardize branch naming.
urangel
reviewed
Feb 5, 2025
Comment on lines
+53
to
+62
| ## 1. Overview | ||
|
|
||
| This document provides a comprehensive overview of the BloodHound branching and release strategy. It serves as the foundation for how code moves from development branches through release branches. | ||
|
|
||
| ## 2. Motivation & Goals | ||
|
|
||
| - **Short-Lived Branches** - Avoid confusion and drift by limiting the number of branches that require long-term maintenance and terminating most branches once their assigned release is complete. | ||
| - **Consistent Release Process** - Standardize how we name, manage, and merge release branches. | ||
| - **Isolated Fixes** - Ensure hotfixes do not inadvertently pick up unreleased features from the default branch. | ||
|
|
There was a problem hiding this comment.
It might be good to have a section for scope in the document. Who does this document pertain to? Who is expected to follow these processes? For example, a community contributor would not have knowledge of our internal ticketing details and may have to contribute with branches named differently.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Describe your changes in detail
Motivation and Context
This PR addresses: [GitHub issue or Jira ticket number]
Why is this change required? What problem does it solve?
How Has This Been Tested?
Please describe in detail how you tested your changes.
Include details of your testing environment, and the tests you ran to
see how your change affects other areas of the code, etc.
Screenshots (optional):
Types of changes
Checklist: