change default branch from 'master' to 'main'

[jameslamb]

In #7034, we have broad agreement amongst maintainers to change the default branch from master to main, for the reasons described there.

I talked with @guolinke and @shiyu1994 in the private maintainer chat about this too (reminder to other maintainers to please join that chat!) and they agreed with doing this close in time to when we moved out of the Microsoft/ org.

This proposes doing that.

This PR updates all references to master (except PR CI triggers, which should temporarily allow master and main).

After this PR

Once this has at least 2 approvals and is merged, I'll do all the remaining mostly-manual work to complete this migration, including updating all open PRs. See "Approach" in #7034 for a list of steps.

update: using GitHub's branch renaming, all open PRs will automatically be retargeted to main.

Expected Impact

copied from #7034

• ❌ raw.githubusercontent.com links will break
  • example: https://raw.githubusercontent.com/dask/dask/refs/heads/master/.git-blame-ignore-revs
• ❌ any git pull explicitly referencing master will not work
• ❌ external-to-this-repo guides referencing the master branch may be incorrect (broken links, advice to use git commands that no longer work, etc.)
• ❌ contributors may need to update their forks and local clones

[borchero]

Thanks! Just two questions :)

[borchero]

Why do we keep master here?

[jameslamb]

I believe we need it for CI on this PR to still be triggered.

So it could be removed as soon as this is merged and the default branch switches to main.

[jameslamb]

I've put up a follow-up removing these: #7353

[borchero]

Similar question: aren't all PRs immediately rebased after rename?

[jameslamb]

@guolinke asked that we preserve master indefinitely (but just not update it any more), so I was thinking of doing this as changing the default branch not "renaming" master to main.

GitHub handles a lot with renaming (https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/renaming-a-branch), but the renaming does not extend to SSH-base git clones

$ git clone --branch master git@github.com:dask/distributed.git
Cloning into 'distributed'...
fatal: Remote branch master not found in upstream origin

But thinking about it some more, renaming via GitHub's feature for that (https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/renaming-a-branch) would be easier and seems like it's handle most redirections.

And I guess anyone directly trying to clone from master probably really wants "latest" and it'd be better to alert them to the need to update to main than for them to silently keep getting a frozen-in-time-branch.

@guolinke could you read that link and let me know if it'd be ok to rename master to main instead of preserving master?

I guess this is what other projects have done, e.g. if you go to https://github.com/dask/distributed/tree/master you'll be redirected to https://github.com/dask/distributed/tree/main.

[borchero]

Yeah, I'd be strongly in favor of renaming via GitHub's dedicated feature 😅

[jameslamb]

I've asked @guolinke for his opinion in the private maintainer chat too. Hoping we can come to an agreement here and resolve this to make it part of the v4.7.0 release.

I know he's busy with other things and may be hard to reach.

If we don't hear back by July 25 (that'll have been 2 months), I'm comfortable moving forward with the "renaming" option and with the release. I always want to defer to Guolin's opinion on major things like this affecting the project, but we also need to keep the project moving forward and he already approved making the default branch main (it's only the exact mechanism that's a question here).

[jameslamb]

Hey @borchero , Guolin approved doing the rename privately, so I'm ready to move forward with that approach. Thanks for the nudge!

I still think we need these master lines in GitHub Actions configurations temporarily to keep CI running on this PR (and then a follow-up PR to remove them).

I've also updated the plan in the "Approach" section of #7034

Could you take another look here and approve if you think the PR has all the changes we'd want on the default branch before making the switch?

Once you approve this, I'll merge it and work on all the other steps. And then we could hopefully be ready to do the release as soon as this week 😁

[jameslamb]

No other maintainer has clicked "approve" on this, but it has many other forms of approval:

• verbal approval from @guolinke and @shiyu1994 in the private maintainer chat
• I interpret @borchero 's review as supportive now that we're doing the GitHub "rename default branch" approach (change default branch from 'master' to 'main' #7287 (comment))
• 👍🏻 reaction from @jmoralez on [RFC] rename 'master' branch to 'main'? #7034

Given all that, I feel comfortable using admin powers to merge this without an approval.

I just made the following changes to support that:

• removed the ruleset on master that was conflicting with the classic branch protection (think this was inherited from Microsoft)
• temporarily modified the branch protection on master to allow myself to merge without an approval

I'm sorry to do this, but we need to get a new release out in the next 20 days (#7352) and we'd agreed a long time ago to make this a part of the release alongside changing the GitHub org.

I know everyone has different challenges making time for LightGBM, but I hope in the future folks will be able to devote a bit more time to reviews here so things can move forward faster. I promise to use this power very sparingly in the future, but I'd be willing to do it again for other time-sensitive needs like security vulnerabilities or CRAN fix-this-or-get-archived threats.

[jameslamb]

I've re-set the branch protection to again prevent admin merges.