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
-
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