Change default branch name

[tschneidereit]

As a policy, the Bytecode Alliance is changing the default branch names in all repositories. We would like for all projects to change the default to main by June 26. (We mention June 26th because there is some suggestion that GitHub may be adding the ability to make this process more seamless. Feel free to wait for that, but only up to June 26.)

Please consider this a tracking issue. It is not intended for public debate.

• Change branch name
• Update CI
• Update build scripts
• Update documentation

[tschneidereit]

(To be clear, we'll provide support and documentation for applying this uniformly, and with as little disruption as possible.)

[alexcrichton]

In terms of technical doo-dads, this is relatively easily to do functionally today. We'd just push a new branch called main, switch via the GitHub UI this repo's default branch to the new branch, and then delete the old master branch.

One issue though is how to deal with active PRs. Deletion of the master branch will auto-close all open PRs against it, and ideally we'd have them retarget the main branch instead of get auto-closed. (a magical github feature may make this much easier to manage)

One other perhaps minor side issue to investigate is I'm not actually sure how Cargo deals with git dependencies that don't specify a branch but don't have the default branch as master. For example we may break:

[dependencies]
wasmtime = { git = 'https://github.com/bytecodealliance/wasmtime' }

I think it's fine to break that, but we'll want to detect that an probably open a Cargo issue to recognize a missing branch = '..' annotation as "pick up the default branch from the remote" rather than "assume the branch is called master"

[bjorn3]

The default branch is master:

https://github.com/rust-lang/cargo/blob/9d84c0c734329a43ca79d748e5624fd8db5706bb/src/cargo/core/source/source_id.rs#L117

It seems to be possible to get the commit associated to the default branch using git ls-remote origin HEAD.

[tschneidereit]

Thank you for the overview, @alexcrichton, and for the research into cargo, @bjorn3!

One issue though is how to deal with active PRs. Deletion of the master branch will auto-close all open PRs against it, and ideally we'd have them retarget the main branch instead of get auto-closed. (a magical github feature may make this much easier to manage)

That Github have indicated that they're working on something here was the main reason why, in the BA Steering Group meeting today, we decided to wait until the end of next week before doing this. Clearly they can make this go much more seamless, so 🤞 they do! At the same time, we also don't want to wait indefinitely, and think the fallout of doing it without the kinds of mitigation only Github could enable is acceptable.

[tschneidereit]

Deletion of the master branch will auto-close all open PRs against it, and ideally we'd have them retarget the main branch instead of get auto-closed.

Turns out it's possible to re-target PRs (by pressing the Edit button next to the PR's title), so as long as we do that before deleting the master branch, we should be fine in this regard.

[pchickey]

One aspect GitHub's official support for this feature might include is redirecting <repo>/{tree, blob}/<branchname>/... urls from the old to the new branchname. I don't know how prevalent it is for external URLs to link to trees or blobs in the this repo but we have those sorts of links all over the WebAssembly repos. I've inquired whether this will be the case and if so, whether we should hold off converting until official support lands.

[alexcrichton]

For the Cargo side of things, which again isn't really related to wasmtime nor should it block this transition, as a heads up I've got rust-lang/cargo#8364 cooking which should improve the state of things.

[alexcrichton]

Done in #1924!