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},
    ],

[gr2m]

Yes

[JamesSingleton]

Yes

Interesting, even though I have that setup https://github.com/americanexpress/iguazu-rest/blob/main/package.json#L97-L110 I still get

This test run was triggered on the branch main, while semantic-release is configured to only publish from master, therefore a new version won’t be published.

[DanielTamkin]

@JamesSingleton i got a similar error too, seems there are no quick fixes apart from developing a solid fix. Attempting to do so over on #1649, but it's taking some time.

[JamesSingleton]

@DanielTamkin yeah not sure how @TimoBechtel got it working for his repos

[DanielTamkin]

Me either. From my studying of the code base so far, I've found that master is literally hard-coded in everything from link generators, to git parsing. Seems to me that a simple config change would still bring a host of other errors.

Edit: @JamesSingleton discovered a solution by updating semantic-release to 17.X.

[JamesSingleton]

But

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

Should override it though?

[gr2m]

It should, yes, I use that in several of my own repositories

A simplified version where I only use the default branch: https://github.com/probot/pino/blob/cc8cc98b51dfd2d6e31140b7ac90ad07d8b6b122/package.json#L34-L38

I'm sure I use the full replacement in some repositories too, I'd need to look them up

[JamesSingleton]

@gr2m so any idea on why GitHub actions is saying that iguazu-rest is setup to use master when it is setup to use main. Could it be the version of semantic-release?

[DanielTamkin]

That's interesting @gr2m! Tried that before and semantic-release still assumed master as default... would love to see those full replacements. Wonder if the version has something to do with it.
Edit: Read my mind @JamesSingleton

[JamesSingleton]

@DanielTamkin I think it is. Our iguazu-rest library is on 15.x but our json-parse-context library is on 17.x and released just fine

[JamesSingleton]

@DanielTamkin and @gr2m I just want to confirm that it was the version of semantic-release. I updated iguazu-rest to 17.x and it released just fine.

[amclin]

This seems to have gotten stale.

GitHub now defaults all new repos to use main so main should be added to the default branch regex pattern just like master and next which are equally arbitrary conventions. #1737 should be merged. Anyone hypothetically intentionally using main as a branch name not synonymous with master is already aware of the controversy and decision by GitHub (and others) to move to main.

[gr2m]

We want to merge #1737 but were not able to sufficiently test it yet. It will take as much time as it takes, sorry, we do our best

[PachVerb]

My current semantic-release version is 17.4.4. It is possible to complete the semantic version release, and the default branch main is valid. configure just like this:

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

[brianpooe]

My current semantic-release version is 17.4.4. It is possible to complete the semantic version release, and the default branch main is valid. configure just like this:

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

This is not working for me. Getting the same branches error.

[mkurte]

Sorry, if I'm late to the party. But am I right that it's currently not possible to configure semantic-release to release from a branch called main?

[kleinfreund]

But am I right that it's currently not possible to configure semantic-release to release from a branch called main?

This issue is about adding main to the default configuration for branches. It’s already possible to configure main as a release branch manually.

[mkurte]

But am I right that it's currently not possible to configure semantic-release to release from a branch called main?

This issue is about adding main to the default configuration for branches. It’s already possible to configure main as a release branch manually.

Okay, and how do I configure it?

Neither this:

"release": {
    "extends": "semantic-release-monorepo",
    "branches": [
      "main",
      {
        "name": "beta",
        "prerelease": true
      },
      {
        "name": "alpha",
        "prerelease": true
      }
    ],
    "plugins": [
      "@semantic-release/commit-analyzer",
      "@semantic-release/release-notes-generator",
      "@semantic-release/npm"
    ]
  }

nor this

"release": {
    "extends": "semantic-release-monorepo",
    "branches": [
      {
        "name": "main"
      },
      {
        "name": "beta",
        "prerelease": true
      },
      {
        "name": "alpha",
        "prerelease": true
      }
    ],
    "plugins": [
      "@semantic-release/commit-analyzer",
      "@semantic-release/release-notes-generator",
      "@semantic-release/npm"
    ]
  }

works for me.

[mkurte]

Sorry, my bad. I had a wrong old origin in my package.json where main didn't exist. facepalm

It now works... Please forget what I said.