add "main" as alternative default branch

[TimoBechtel]

New feature motivation

Lots of projects move from "master" as default branch to "main".

I, too, did change all default branches on GitHub to "main".
Changing this would have been a lot easier, if I wouldn't have to edit all the semantic-release configuration files.

Changing the config means, re-adding the default branches list, just to change the default branch to "main"
(correct me if there's a simpler solution).

New feature description

Add "main" to the list of branches in the default configuration.

[gr2m]

We discussed this topic internally, I run into this issue myself. We decided to hold on for now and wait to see if GitHub and the other big git hosting platforms agree on a new default branch name. I agree that it feels like it's going to be "main", but there is no official statement yet.

There are two things we could do to right now.

1. Implement a new setting: defaultBranch. That will replace

    "branches": [
      "+([0-9])?(.{+([0-9]),x}).x",
      "main",
      "next",
      "next-major",
      {
        "name": "beta",
        "prerelease": true
      },
      {
        "name": "alpha",
        "prerelease": true
      }
    ],

   with

    "defaultBranch": "main",

2. Start a pull request to add "main" as default branch out-of-the-box.

---

1. will be helpful either way and I'd suggest to start with that.

And there is no reason to start working on 2., to get an understanding how complicated the change would be.

Neither @pvdlg nor I do have time to work on this right now, so we would appreciate a pull request if anyone wants to work on either of these

[mikebryant]

I also raised this here: semantic-release/gitlab#152
My thinking there is - whatever the default branch that someone has set in the Gitlab configuration, semantic-release should support it, when being run in Gitlab-CI (and therefore having access to those environment variables)

[DanielTamkin]

Is there any progress on this? Seems the git platforms are inching closer to using main, yet still haven't made official statements. I think it would be useful to create a defaultBranch option regardless of this; Allowing more flexibility in future workflows.

This current configuration still gives the error ERELEASEBRANCHES

[gr2m]

Is there any progress on this?

No, but I hope to find some time in August. But if someone would like to

I think it would be useful to create a defaultBranch option regardless of this

Agree. I think we would need to do something similar to what the GitHub Actions team did, and introduce a $default-branch macro: https://github.blog/changelog/2020-07-22-github-actions-better-support-for-alternative-default-branch-names/

So we can configure the branches and defaultBranch independent from each other, e.g.

    defaultBranch: "main",
    branches: [
      '+([0-9])?(.{+([0-9]),x}).x',
      '$default-branch',
      'next',
      'next-major',
      {name: 'beta', prerelease: true},
      {name: 'alpha', prerelease: true},
    ],

Or maybe there is a more elegant way, I couldn't look through the code base for this yet.

And with current code base, we cannot support multiple default branches, so e.g. this would not work

    branches: [
      '+([0-9])?(.{+([0-9]),x}).x',
      'main',
      'master',
      'next',
      'next-major',
      {name: 'beta', prerelease: true},
      {name: 'alpha', prerelease: true},
    ],

At least not without significant changes.

[Dhinendran]

@travi @gr2m did you have any solution.

[gr2m]

I did not have time to work on this. If anyone would like to look into implementing the defaultBranch configuration, that'd be great. We would implement it as part of v17, and then swap the default of defaultBranch from master to main in v18

[dargmuesli]

just for the record, https://github.com/github/renaming states that

On October 1, 2020, any new repositories you create will use main as the default branch, instead of master.

[DanielTamkin]

Hacktober fest is coming up! Would personally love to find some time and dive into this codebase with someone to get this moving. Does anyone know a bit about the reasoning behind the error? i.e which dependency is the root cause. Would be helpful so i could start reviewing the source code for both that and this library.

[gr2m]

With the error you mean "ERELEASEBRANCHES"?

I didn't implement the multi-branch release feature, that was all @pvdlg. But I'm pretty sure that all the code is in the semantic-release core package, aka in this repository. As stated in my first comment, I think the best move forward would be to introduce a new "defaultBranch" configuration, which would default to "master" now, but we can change that to "main" in the next breaking release. That way we wouldn't need to overwrite the "branches" setting which is quite complex, if all we want is to support a different default branch for releasing to the "latest" channel

Maybe start out with a pull request containing a failing test, and we take the discussion there?

[DanielTamkin]

Sorry for late reply, very busy semester. Will get on that right now @gr2m

[jpoehnelt]

Is the workaround the following?

branches: [
      '+([0-9])?(.{+([0-9]),x}).x',
      'main',
      'next',
      'next-major',
      {name: 'beta', prerelease: true},
      {name: 'alpha', prerelease: true},
    ],