ADR-006: Branching strategy for rhdh-local development#18
Draft
rm3l wants to merge 16 commits into
Draft
Conversation
Propose a `dev` branch strategy for rhdh-local to unblock next-release development while keeping `main` stable for end users. Assisted-by: Claude
rm3l
force-pushed
the
feat/rhdh-local-branches-and-rhdh-versions
branch
from
51944a2 to
cbef9c1
Compare
GitHub's Mermaid renderer requires `gitGraph` (camelCase), not `gitgraph` (lowercase). Assisted-by: Claude
Add Slack link for PM requirement, clarify upgrade path for existing users, and improve phrasing in context section. Assisted-by: Claude
Clarify that changing the GitHub default branch does not break existing clones; the real issue is that main would need to carry unstable content. Assisted-by: Claude
Add release-1.10, release-2.2 branches and patch tags (v1.10.2, v2.1.1) to all diagrams to show the full branching strategy across multiple release cycles. Assisted-by: Claude
rm3l
force-pushed
the
feat/rhdh-local-branches-and-rhdh-versions
branch
3 times, most recently
from
9a8d3f5 to
b175f41
Compare
Add main merges for v2.1.1 and v2.2 GA, add v1.10.3 patch tag, extend dev to 2.3 work, and remove duplicate commit id text where a tag already shows the same version. Assisted-by: Claude
rm3l
force-pushed
the
feat/rhdh-local-branches-and-rhdh-versions
branch
from
b175f41 to
3f15d4e
Compare
Shorten labels to reduce text overlap and add ★ default markers to Alt 1 and Alt 3 diagrams to clarify which branch is the default at each point. Assisted-by: Claude
Update Alt 1 diagram with release-1.10 as current default, add ★ default markers to Alt 1 and Alt 3, tighten Alt 2 rejection rationale, consolidate divergence negatives, add integration point positive, and trim outdated points. Assisted-by: Claude
Move v1.10.0 tag to release-1.10 branch with default marker, and lowercase "Alternatives considered" heading. Assisted-by: Claude
Interleave release-1.10 patch tags with dev/main 2.1 work to make it clear that maintenance releases happen in parallel with new development. Assisted-by: Claude
Use mainBranchName init config to show "main (default)" in diagrams where the default branch does not change. Assisted-by: Claude
Both the Decision and Alt 2 diagrams used mainBranchName config to rename main to "main (default)" but had no initial commit before the first branch statement, causing GitHub to error with "Current branch (main (default)) has no commits". Assisted-by: Claude
Alt 1: clarify that existing users would need to switch branches at each GA, defeating the simple "pull to upgrade" workflow. Alt 2: focus on the practical downside that the development target branch changes every release cycle, vs. a stable dev branch. Assisted-by: Claude
Assisted-by: Claude
Consistent with Decision and Alt 2 diagrams that label the default branch explicitly. Assisted-by: Claude
Assisted-by: Claude
gazarenkov
reviewed
Jul 9, 2026
gazarenkov
left a comment
gazarenkov
left a comment
Member
There was a problem hiding this comment.
There is one important difference between "usual" flow and rhdh-local we need to emphasize (it may look obvious now):
We fix bugs right do not provide any bug-fix releases
|
|
||
| **Cherry-pick policy**: | ||
| - Version-independent changes (documentation, GitHub Actions dependency updates) can target `main` directly or be cherry-picked between `dev` and `main` | ||
| - RHDH-specific or configuration changes remain on `dev` until the corresponding RHDH version is GA and the `release-x.y` branch is merged into `main` |
Member
There was a problem hiding this comment.
What about bug fixes, are they classified as "RHDH-specific or configuration changes"?
I think it is important to mention (even if may look obvious) - we do not provide bug-fix releases?
| **Cherry-pick policy**: | ||
| - Version-independent changes (documentation, GitHub Actions dependency updates) can target `main` directly or be cherry-picked between `dev` and `main` | ||
| - RHDH-specific or configuration changes remain on `dev` until the corresponding RHDH version is GA and the `release-x.y` branch is merged into `main` | ||
| - Fixes to `release-x.y` branches should be cherry-picked to both `main` and `dev` |
Member
There was a problem hiding this comment.
Do we need to maintain older releases?
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary
devbranch strategy for rhdh-local to unblock next-release development (e.g., PR #256) while keepingmainstable for end userslatest/nextrename scheme) with Mermaid diagrams for eachTest plan
Assisted-by: Claude