Replacing master as the default branch

[romanlutz]

Context: the word master is triggering or at least making people uncomfortable. Haven’t seen a good reason not to do this yet.

https://twitter.com/mislav/status/1270388510684598272?s=21

The new default isn’t really set yet. Could be

• main
• default

Any thoughts?

[MiroDudik]

Thanks for bringing this up! I'm not a huge fan of default. I think I best like main.

Other options are develop (since we're using GitHub workflow), or latest, or current.

[hannawallach]

Yes, thank you! I like main too.

[romanlutz]

I’m still baffled that I never noticed this before :-(
I like all your suggestions @MiroDudik
Let’s see whether @adrinjalali @hildeweerts @kevinrobinson @koaning @MBrouns @riedgar-ms @rihorn2 or others have thoughts as well

[MBrouns]

I have a slight preference to trunk or develop, but don't have anything against main either.

[hannawallach]

One other thing I want to flag is that this relates to something that we'd discussed previously about having a dev or unstable branch and then a release or stable branch, so that folks can still make bigger changes even close to a release.

[riedgar-ms]

@hannawallach I do have a proposal out for making our versioning a bit more robust, and that includes starting to have release branches again:
fairlearn/fairlearn-proposals#11

As for a new name.... I think I'd prefer something like trunk or main to dev if we want to make sure that our main development is always ready-to-ship.

[romanlutz]

So many great suggestions! As a non-native English speaker I'm somewhat confused with trunk. It doesn't seem intuitive to me. Perhaps someone can explain this to me :-)

main seems to have the same kind of intuition as master but without the baggage. dev or develop are intuitive to me as well.

current or latest may be confusing because people may think that it reflects the version that they get when they run pip install fairlearn.

Maybe I'm overthinking this, but those are the thoughts I had when seeing these now.

[romanlutz]

Just came across this: https://github.com/dfm/rename-github-default-branch/blob/main/README.md

[MBrouns]

So many great suggestions! As a non-native English speaker I'm somewhat confused with trunk. It doesn't seem intuitive to me. Perhaps someone can explain this to me :-)

I think it came from SVN originally but I've always seen it as the trunk of a tree, from which branches spawn

[adrinjalali]

My only preference is to use what the rest of the community is gonna use since there are a bunch of scripts around which rely on the name of the "main" branch. It seems the community is converging on main which I'm happy with.

[hildeweerts]

I like main, but I'm happy with any of the other suggestions as well.

[riedgar-ms]

This implies that GitHub is going to go with main:
https://www.theregister.com/2020/06/15/github_replaces_master_with_main/
although I've not yet turned up an official announcement from the GitHub site yet, just the tweet.

Unless we really don't like their final choice, I suggest we stick to whatever is chosen by GitHub for the sake of simplicity.

[hildeweerts]

Does anybody know what GitHub is going to go with? I couldn't find any announcements dated later than June 15.

[adrinjalali]

AFAIK they haven't finished the work yet, so we don't know for sure, but I'm almost certain it's main.

In so far as the tasks go, I've compiled a list using the feedback I got from different places here: https://discuss.python.org/t/communitys-take-on-changing-master-branch-to-main/4462/12?u=adrinjalali

Not all of them are needed on this repo, but it's a good starting point.

[riedgar-ms]

Thanks for compiling that list of steps @adrinjalali . Funnily enough, we had an internal email this week saying that detailed instructions are coming. I expect there may be some automation on the GitHub side to take care of some of those (e.g. redoing any open PRs) although things like redoing the build definitions are going to remain manual.

[hildeweerts]

FYI: https://github.com/github/renaming

[riedgar-ms]

Thanks for highlighting that update @hildeweerts !

While I can see the argument that we should make the change sooner, I'm inclined to follow the suggestion on that page, and wait for the automation to become available. Although we could use it as a forcing function, to clear our PR backlog :-)

[romanlutz]

I think I'd rather wait for the seamless move than spend hours fixing things all over the place. I'm not 100% convinced even the seamless move will fix things, though. I'm particularly thinking of the automation that builds the docs and pushes that to the other repo's master branch. If we had more info on what the seamless move will include we could judge whether it's worth waiting or not. What do you think?

[hildeweerts]

I'm okay with waiting a bit longer for the 'seamless' move. Perhaps it'd make sense though to set a go/no go date in case Github takes longer than expected.

[romanlutz]

Let me see whether I can get some more details on just how seamless this will be... if it's not sufficient I'd say there's no particularly good reason to wait.

[romanlutz]

I still can't find information on when this will happen. I am more and more thinking that @hildeweerts was right in suggesting a go/no go date :-)

So I'll just propose doing this during the week of December 21 and volunteer myself. Thoughts?

One option that would probably cause very little disruption is if I try this around the holidays in December, because I don't expect too many people to write code around that time. The parts that may cause some trouble:

• pipelines on Azure, GitHub, and CircleCI need to be repointed at main branch
• website repo fairlearn.github.io needs to consume main branch as opposed to master branch

[adrinjalali]

last update was that it should happen by the end of the year: https://github.com/github/renaming#later-this-year-seamless-move-for-existing-repositories-

I'd say ask your colleagues when they're planning to launch this? :P

[romanlutz]

It says January 2021, that's all I could gather internally as well. Fine, I'll wait another month...

[adrinjalali]

GitHub now properly supports renaming the branch: https://github.com/github/renaming

Renaming a branch will:

Re-target any open pull requests
Update any draft releases based on the branch
Move any branch protection rules that explicitly reference the old name
Update the branch used to build GitHub Pages, if applicable
Show a notice to repository contributors, maintainers, and admins on the repository homepage with instructions to update local copies of the repository
Show a notice to contributors who git push to the old branch
Redirect web requests for the old branch name to the new branch name
Return a "Moved Permanently" response in API requests for the old branch name

[romanlutz]

In addition to this, we'll also have to manually adjust the website build.

[romanlutz]

Trying my luck now! Stay tuned.

[romanlutz]

The PR description of #694 has all the instructions on adjusting your local env.