Open discussion: rename the default branch ?

[jrfnl]

In a way a "bit late to the party", but should the default branch be renamed away from master ?

And if so, what would be the preferred new name ?

Some options:

• A lot of repos have gone with main. For a "one branch" repo, that would be an obvious choice.
• As an alternative, but that would also involve a different branching strategy, it could be considered to have a stable branch as a release branch and have a develop branch as the default PR branch. For a new release develop would then be merged into stable.

Opinions ?

[Potherca]

I'm in favor of moving away from master.

I'd say, for now, lets just move to main ASAP (since we're making other soft-breaking changes to our dev environment anyway).

We can always move to something more elaborate when needed.

My 2️⃣🪙

[Potherca]

Places that need editing for this rename:

composer-installer/.github/ISSUE_TEMPLATE/bug_report.md

Line 52 in 5227b24

## Tested against `master` branch?

composer-installer/.github/workflows/integrationtest.yml

Line 8 in 8ab9bb5

- master

composer-installer/.github/workflows/quicktest.yml

Line 8 in 8ab9bb5

- master

composer-installer/CONTRIBUTING.md

Line 10 in 8ab9bb5

[a code of conduct]: https://github.com/PHPCSStandards/composer-installer/blob/master/CODE_OF_CONDUCT.md

composer-installer/CONTRIBUTING.md

Line 134 in 8ab9bb5

New releases (and any related tags) are always created from the `master` branch.

[Potherca]

@jrfnl Do we want to make this change as well for the v1 release?

[jrfnl]

If we make this change, then, yes, the 1.0 release would be a good time to do so.

I suggest doing it just before the 1.0 release.
That way, if there are people who use dev-master, their workflow won't be broken without a notification (i.e. a mention in the release notes for the 1.0 release).

[paulshryock]

Another vote +1 for main branch just before the 1.0 release.

[Potherca]

Resolved by #201

[danepowell]

That way, if there are people who use dev-master, their workflow won't be broken without a notification

Eh... consider me one of those people whose workflow was broken without notification. I thought you might be able to prevent breakage by adding a branch alias, but it seems like that's not possible: composer/composer#11301

[jrfnl]

@danepowell Out of curiosity: why were you using the master branch instead of a tagged release ?

[danepowell]

We needed #167 which was only in master at the time.

[jrfnl]

@danepowell Interesting. That bug was never reported by anyone, but clearly people (you) did run into it. Thanks for letting me know.

The good news is, of course, that the bug fix is included in the 1.0.0 release, so you should be able to switch back to versioned updates now.

[ntwb]

Hey 👋🏼

A project I work on has also just been caught out by this change

One of the packages we use pushed a fix yesterday changing from dev-master to dev-main but they've not yet been able to tag and publish a new release yet...

• PHPOffice/PhpSpreadsheet@247f9cb

Whilst we work to resolve these issues on our project, we'll create upstream updates for the packages we use and hoping they're maintained and can push new releases soon as this will be tricky for packages that are not so well maintained

A quick GitHub search shows 14 of the first 50 search results (3481 total results) use dev-master

Unsure of a workable solution, though a solution from Composer would be ideal, I've subscribed to composer/composer#11301 and will be interested in replies there...

Edit: Whilst we run our build script using the --no-dev flag to install packages as part of our deployment process Composer still requires that require-dev packages satisfy version requirements as per this message displayed:

• "Running update with --no-dev does not mean require-dev is ignored, it just means the packages will not be installed. If dev requirements are blocking the update you have to resolve those problems."

[Potherca]

@jrfnl Should we create a branch master from mainkeep the masterbranch which I accidentally creatyed from main for now until things are further resolved?

Apparently I just created one (I was fiddling around with the UI and apparent filling something in already creates the branch)

[jrfnl]

@Potherca I don't think so. Yes, the change is inconvenient for people, however:

• People shouldn't be using dev-master (or dev-main) anyway.
• Now the 1.0 release has been tagged, I expect we can go back to rapid releases for bug fixes (if any), which removes the need for anyone using dev-master/dev-main.
• Now the 1.0 release has been tagged, people won't need to update the version constraints on every 0.x minor release anymore either (as those are treated as majors).

It's also a one-time only change (at least that's the intention) and we executed it in the most considerate way possible:

• We has a long running open issue about the rename (this one).
• We did the rename just before the release.
• The rename was mentioned in the changelog of the release.

I'd recommend for people who choose to use dev- branches of repos to watch the repo or, at the very least, watch release notifications of those repos, but that's not our responsibility.

[danepowell]

The official suggestion from composer in composer/composer#11301 is that you should create a 1.x branch alias for main and projects should use that instead of dev-master or dev-main. That means not keeping a duplicate branch.

[ntwb]

Should we ~create a branch master from main~keep the masterbranch which I accidentally creatyed from main for now until things are further resolved?

Apparently I just created one (I was fiddling around with the UI and apparent filling something in already creates the branch)

Oh, this could be why I've not encounted this previously.

GitHub redirects renamed branches, but only if they were renamed

https://github.blog/changelog/2020-07-17-links-to-deleted-branches-now-redirect-to-the-default-branch/