Skip to content

docs(contributing): drop --branch next/major from clone snippet; clarify PR target#3198

Merged
dr-bonez merged 2 commits into
masterfrom
helix/contributing-pr-target-master
May 1, 2026
Merged

docs(contributing): drop --branch next/major from clone snippet; clarify PR target#3198
dr-bonez merged 2 commits into
masterfrom
helix/contributing-pr-target-master

Conversation

@helix-nine
Copy link
Copy Markdown
Contributor

Why

The "Cloning the Repository" snippet in CONTRIBUTING.md tells you to clone with --branch next/major:

git clone --recursive https://github.com/Start9Labs/start-os.git --branch next/major

…but master is the actual default branch and the PR target. I tripped on this myself and opened #3196 against next/major before noticing every other recent PR (#3190#3197) targets master. Easy mistake to make from the doc as written.

What

  • Drop the --branch next/major flag from the clone command so a fresh checkout lands on the default branch.
  • Add a short paragraph clarifying that master is the PR target and next/major is the long-lived branch for the next major release (only target it for changes that must wait for that bump).

No build / behaviour changes — docs only.

…ify PR target

The recommended clone command pinned `--branch next/major`, which left
contributors landing on a long-lived feature branch instead of `master`
(the actual default branch and PR target). I tripped on this myself
and opened #3196 against `next/major` before noticing every other open
PR targets `master`.

Drop the `--branch next/major` flag so a fresh clone lands on the
default, and add a short note explaining that `master` is the PR
target while `next/major` is reserved for the next major release.
Comment thread CONTRIBUTING.md Outdated
@helix-nine
Copy link
Copy Markdown
Contributor Author

Applied verbatim and pushed.

Thanks @dr-bonez — adopted your wording verbatim in 5b2f5420. The "current release vs next/{patch,minor,major}" framing is much more useful than my one-line gloss; specifically the "if the current latest release is a pre-release, new features land on master" rule is exactly the bit I would have gotten wrong from outside. PR #3198 is updated and ready when you have a moment.

@dr-bonez dr-bonez merged commit 7355ec4 into master May 1, 2026
25 checks passed
@dr-bonez dr-bonez deleted the helix/contributing-pr-target-master branch May 1, 2026 17:04
@helix-nine
Copy link
Copy Markdown
Contributor Author

Thanks @dr-bonez!

Adopt the maintainer-authored explanation of the branch-targeting
policy verbatim: master tracks the current release (and during a
beta.X pre-release, PRs for new features and bugfixes land there),
with next/{patch,minor,major} holding work waiting for the
corresponding future release.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants