We have both main and master. Let's drop both and just rely on a global next + version-specific nexts.
#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.
-
mainwas (until about a couple hours ago) only one commit behindmaster, and I recently fixed that. Let's complete the switch frommastertomainand deletemaster, so we have only one branch.Though...maybe we should just drop
master/mainentirely 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.nextpoints to the tip of tree. A GH Action will updatenext-vNwhereNis 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.docspoints to the tip of tree for the docs. Updates todocs/in this branch sync tonext(in the same waynextsyncs tonext-vN, but updates todocs/innextdo not sync to this.gh-pageswill see updates automatically fromdocsand (to the archive only)release-vN.Beta Was this translation helpful? Give feedback.
All reactions