We have both main
and master
. Let's drop both and just rely on a global next
+ version-specific next
s.
#2952
Closed
dead-claudia
started this conversation in
Meta/Feedback
Replies: 3 comments
-
cc @MithrilJS/collaborators |
Beta Was this translation helpful? Give feedback.
0 replies
-
Yeah agreed |
Beta Was this translation helpful? Give feedback.
0 replies
-
And completed. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
main
was (until about a couple hours ago) only one commit behindmaster
, and I recently fixed that. Let's complete the switch frommaster
tomain
and deletemaster
, so we have only one branch.Though...maybe we should just drop
master
/main
entirely and rely on the version branches instead. It'd be a lot simpler to work with, and it'd avoid some future confusion. I'm imagining the following system:release-v{0,1,2,...}
points to the commit used to generate the latest release for that major version. These would only be updated on publish.next-v{0,1,2,...}
points to the tip of tree for docs for that version, including unreleased updates.next
points to the tip of tree. A GH Action will updatenext-vN
whereN
is the current major version innext
, so it can be a one-time setup. If it can't fast-forward (preferred) or rebase against the currentnext-vN
, I'll have it create a pull request.docs
points to the tip of tree for the docs. Updates todocs/
in this branch sync tonext
(in the same waynext
syncs tonext-vN
, but updates todocs/
innext
do not sync to this.gh-pages
will see updates automatically fromdocs
and (to the archive only)release-vN
.Beta Was this translation helpful? Give feedback.
All reactions