Skip to content

Conversation

@sensei-hacker
Copy link
Member

@sensei-hacker sensei-hacker commented Jan 5, 2026

User description

Clarify that the merge flow is: maintenance-9.x → master → maintenance-10.x

This keeps master synchronized with the current version branch. If contributors accidentally branch from master, they get current version code without pulling in breaking changes from the next major version.

Changes:

  • Emphasize master is NOT a PR target (receives merges only)
  • Update merge flow in Development.md and release-create.md
  • Clarify backward compatibility vs breaking changes
  • Add maintainer workflow examples showing 2-step merge process

PR Type

Documentation


Description

  • Clarifies merge flow: maintenance-9.x → master → maintenance-10.x

  • Emphasizes master is NOT a PR target, receives merges only

  • Adds detailed maintainer workflow examples with step-by-step merge process

  • Removes redundant Master Branch section, consolidates branching guidance


Diagram Walkthrough

flowchart LR
  m9["maintenance-9.x<br/>Current version"] -- "merge" --> master["master<br/>Current version mirror"]
  master -- "merge" --> m10["maintenance-10.x<br/>Next major version"]
  m10 -- "future cycle" --> master2["master<br/>Next version mirror"]
Loading

File Walkthrough

Relevant files
Documentation
Development.md
Restructure branching documentation with merge flow clarity

docs/development/Development.md

  • Updated master branch description to emphasize it tracks current
    version via merges
  • Removed redundant Master Branch section, consolidating guidance
  • Clarified merge flow as maintenance-9.x → master → maintenance-10.x
  • Added detailed maintainer workflow with 2-step merge process and bash
    examples
  • Explained rationale for using master as intermediate step
  • Updated example timeline to show master as mirror of current version
+23/-17 
release-create.md
Update branch usage guidance and merge flow direction       

docs/development/release-create.md

  • Clarified branch usage with explicit backward compatibility language
  • Updated merge flow direction from maintenance-9.x → master →
    maintenance-10.x
  • Added explicit statement that master is NOT a PR target
  • Improved clarity on breaking changes vs non-breaking changes targeting
+4/-4     

Clarify that the merge flow is: maintenance-9.x → master → maintenance-10.x

This keeps master synchronized with the current version branch, so if
contributors accidentally branch from master they get current version
code without pulling in breaking changes from the next major version.

Key changes:
- Emphasize master is NOT a PR target (receives merges only)
- Update merge flow documentation in both Development.md and release-create.md
- Clarify backward compatibility vs breaking changes
- Add maintainer workflow examples showing 2-step merge process
The 'Choosing the Right Target Branch' section already covers that
master is not a PR target. Lead with what contributors should do
rather than what they should not do.
@sensei-hacker sensei-hacker marked this pull request as ready for review January 5, 2026 05:56
@qodo-code-review
Copy link
Contributor

PR Compliance Guide 🔍

All compliance sections have been disabled in the configurations.

@qodo-code-review
Copy link
Contributor

PR Code Suggestions ✨

No code suggestions found for the PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant