feat: add main branch to default release branch config (#1737)

Co-authored-by: Andrei Danilov <andreialexandr.danilov@gmail.com>
Co-authored-by: Oriol Torrillas <otorrillas@gmail.com>
Co-authored-by: Matt Travi <126441+travi@users.noreply.github.com>

README.md

@@ -73,7 +73,7 @@ This way no human is directly involved in the release process and the releases a
 
 ### Triggering a release
 
-For each new commit added to one of the release branches (for example: `master`, `next`, `beta`), with `git push` or by merging a pull request or merging from another branch, a CI build is triggered and runs the `semantic-release` command to make a release if there are codebase changes since the last release that affect the package functionalities.
+For each new commit added to one of the release branches (for example: `master`, `main`, `next`, `beta`), with `git push` or by merging a pull request or merging from another branch, a CI build is triggered and runs the `semantic-release` command to make a release if there are codebase changes since the last release that affect the package functionalities.
 
 **semantic-release** offers various ways to control the timing, the content and the audience of published releases.
 See example workflows in the following recipes:

docs/developer-guide/js-api.md

@@ -16,6 +16,7 @@ try {
       branches: [
         "+([0-9])?(.{+([0-9]),x}).x",
         "master",
+        "main",
         "next",
         "next-major",
         { name: "beta", prerelease: true },

docs/recipes/ci-configurations/github-actions.md

@@ -19,15 +19,15 @@ Find more detail about configuring npm to publish with provenance through semant
 
 ### `.github/workflows/release.yml` configuration for Node projects
 
-The following is a minimal configuration for [`semantic-release`](https://github.com/semantic-release/semantic-release) with a build running on the latest LTS version of Node when a new commit is pushed to a `master` branch.
+The following is a minimal configuration for [`semantic-release`](https://github.com/semantic-release/semantic-release) with a build running on the latest LTS version of Node when a new commit is pushed to a `master/main` branch.
 See [Configuring a Workflow](https://help.github.com/en/articles/configuring-a-workflow) for additional configuration options.
 
 ```yaml
 name: Release
 on:
   push:
     branches:
-      - master
+      - master # or main
 
 permissions:
   contents: read # for checkout

docs/recipes/ci-configurations/gitlab-ci.md

@@ -58,7 +58,7 @@ This example is a minimal configuration for **semantic-release** with a build ru
 **Note**: The`semantic-release` execution command varies depending if you are using a [local](../../usage/installation.md#local-installation) or [global](../../usage/installation.md#global-installation) **semantic-release** installation.
 
 ```yaml
-# The release pipeline will run only on the master branch a commit is triggered
+# The release pipeline will run only on the master/main branch a commit is triggered
 stages:
   - release
 
@@ -71,7 +71,7 @@ release:
   script:
     - semantic-release
   rules:
-    - if: $CI_COMMIT_BRANCH == "master"
+    - if: $CI_COMMIT_BRANCH == "master" # or main
 
 release:
   image: node:12-buster-slim
@@ -82,7 +82,7 @@ release:
   script:
     - semantic-release
   rules:
-    - if: $CI_COMMIT_BRANCH == "master"
+    - if: $CI_COMMIT_BRANCH == "master" # or main
 ```
 
 ### `package.json` configuration

docs/recipes/release-workflow/distribution-channels.md

@@ -4,12 +4,12 @@ This recipe will walk you through a simple example that uses distribution channe
 
 This example uses the **semantic-release** default configuration:
 
-- [branches](../../usage/configuration.md#branches): `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'next', 'next-major', {name: 'beta', prerelease: true}, {name: 'alpha', prerelease: true}]`
+- [branches](../../usage/configuration.md#branches): `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'main', 'next', 'next-major', {name: 'beta', prerelease: true}, {name: 'alpha', prerelease: true}]`
 - [plugins](../../usage/configuration.md#plugins): `['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/npm', '@semantic-release/github']`
 
 ## Initial release
 
-We'll start by making the first commit of the project, with the code for the initial release and the message `feat: initial commit` to `master`. When pushing that commit, **semantic-release** will release the version `1.0.0` and make it available on the default distribution channel which is the dist-tag `@latest` for npm.
+We'll start by making the first commit of the project, with the code for the initial release and the message `feat: initial commit` to `master` or `main`. When pushing that commit, **semantic-release** will release the version `1.0.0` and make it available on the default distribution channel which is the dist-tag `@latest` for npm.
 
 The Git history of the repository is:
 
@@ -19,7 +19,7 @@ The Git history of the repository is:
 
 ## Releasing a bug fix
 
-We can now continue to commit changes and release updates to our users. For example we can commit a bug fix with the message `fix: a fix` to `master`. When pushing that commit, **semantic-release** will release the version `1.0.1` on the dist-tag `@latest`.
+We can now continue to commit changes and release updates to our users. For example we can commit a bug fix with the message `fix: a fix` to `master` or `main`. When pushing that commit, **semantic-release** will release the version `1.0.1` on the dist-tag `@latest`.
 
 The Git history of the repository is now:
 
@@ -63,7 +63,7 @@ We now want to develop a smaller, non-breaking feature. Its scope is small enoug
 
 If we were to commit that feature on `next` only a subset of users would get it, and we would need to wait for the end of our feedback period in order to make both the big and the small feature available to all users.
 
-Instead, we develop that small feature commit it to `master` with the message `feat: a small feature`. When pushing that commit, **semantic-release** will release the version `1.1.0` on the dist-tag `@latest` so all users can benefit from it right away.
+Instead, we develop that small feature commit it to `master` or `main` with the message `feat: a small feature`. When pushing that commit, **semantic-release** will release the version `1.1.0` on the dist-tag `@latest` so all users can benefit from it right away.
 
 The Git history of the repository is now:
 
@@ -78,7 +78,7 @@ The Git history of the repository is now:
 
 ## Porting a feature to next
 
-Most of our users now have access to the small feature, but we still need to make it available to our users using the `@next` dist-tag. To do so we need to merge our changes made on `master` (the commit `feat: a small feature`) into `next`. As `master` and `next` branches have diverged, this merge might require to resolve conflicts.
+Most of our users now have access to the small feature, but we still need to make it available to our users using the `@next` dist-tag. To do so we need to merge our changes made on `master` or `main` (the commit `feat: a small feature`) into `next`. As `master`/`main` and `next` branches have diverged, this merge might require to resolve conflicts.
 
 Once the conflicts are resolved and the merge commit is pushed to `next`, **semantic-release** will release the version `2.1.0` on the dist-tag `@next` which contains both our small and big feature.
 
@@ -91,14 +91,14 @@ The Git history of the repository is now:
 |  * feat: a big feature \n\n BREAKING CHANGE: it breaks something # => v2.0.0 on @next
 |  * fix: fix something on the big feature # => v2.0.1 on @next
 *  | feat: a small feature # => v1.1.0 on @latest
-|  * Merge branch master into next # => v2.1.0 on @next
+|  * Merge branch master/main into next # => v2.1.0 on @next
 ```
 
 ## Adding a version to latest
 
-After a period of feedback from our users using the `@next` dist-tag we feel confident to make our big feature available to all users. To do so we merge the `next` branch into `master`. There should be no conflict as `next` is strictly ahead of `master`.
+After a period of feedback from our users using the `@next` dist-tag we feel confident to make our big feature available to all users. To do so we merge the `next` branch into `master`/`main`. There should be no conflict as `next` is strictly ahead of `master`/`main`.
 
-Once the merge commit is pushed to `master`, **semantic-release** will add the version `2.1.0` to the dist-tag `@latest` so all users will receive it when installing out module with `npm install example-module`.
+Once the merge commit is pushed to `master`/`main`, **semantic-release** will add the version `2.1.0` to the dist-tag `@latest` so all users will receive it when installing out module with `npm install example-module`.
 
 The Git history of the repository is now:
 
@@ -109,9 +109,9 @@ The Git history of the repository is now:
 |  * feat: a big feature \n\n BREAKING CHANGE: it breaks something # => v2.0.0 on @next
 |  * fix: fix something on the big feature # => v2.0.1 on @next
 *  | feat: a small feature # => v1.1.0 on @latest
-|  * Merge branch master into next # => v2.1.0 on @next
+|  * Merge branch master/main into next # => v2.1.0 on @next
 | /|
-*  | Merge branch next into master # => v2.1.0 on @latest
+*  | Merge branch next into master/main # => v2.1.0 on @latest
 ```
 
-We can now continue to push new fixes and features on `master`, or a new breaking change on `next` as we did before.
+We can now continue to push new fixes and features on `master`/`main`, or a new breaking change on `next` as we did before.

docs/recipes/release-workflow/maintenance-releases.md

@@ -4,12 +4,12 @@ This recipe will walk you through a simple example that uses Git branches and di
 
 This example uses the **semantic-release** default configuration:
 
-- [branches](../../usage/configuration.md#branches): `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'next', 'next-major', {name: 'beta', prerelease: true}, {name: 'alpha', prerelease: true}]`
+- [branches](../../usage/configuration.md#branches): `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'main', 'next', 'next-major', {name: 'beta', prerelease: true}, {name: 'alpha', prerelease: true}]`
 - [plugins](../../usage/configuration.md#plugins): `['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/npm', '@semantic-release/github']`
 
 ## Initial release
 
-We'll start by making the first commit of the project, with the code for the initial release and the message `feat: initial commit`. When pushing that commit, on `master` **semantic-release** will release the version `1.0.0` and make it available on the default distribution channel which is the dist-tag `@latest` for npm.
+We'll start by making the first commit of the project, with the code for the initial release and the message `feat: initial commit`. When pushing that commit, on `master`/`main` **semantic-release** will release the version `1.0.0` and make it available on the default distribution channel which is the dist-tag `@latest` for npm.
 
 The Git history of the repository is:
 
@@ -21,7 +21,7 @@ The Git history of the repository is:
 
 We now decide to drop Node.js 6 support for our package, and require Node.js 8 or higher, which is a breaking change.
 
-We commit that change with the message `feat: drop Node.js 6 support \n\n BREAKING CHANGE: Node.js >= 8 required` to `master`. When pushing that commit, **semantic-release** will release the version `2.0.0` on the dist-tag `@latest`.
+We commit that change with the message `feat: drop Node.js 6 support \n\n BREAKING CHANGE: Node.js >= 8 required` to `master`/`main`. When pushing that commit, **semantic-release** will release the version `2.0.0` on the dist-tag `@latest`.
 
 The Git history of the repository is now:
 
@@ -34,7 +34,7 @@ The Git history of the repository is now:
 
 One of our users request a new feature, however they cannot migrate to Node.js 8 or higher due to corporate policies.
 
-If we were to push that feature on `master` and release it, the new version would require Node.js 8 or higher as the release would also contain the commit `feat: drop Node.js 6 support \n\n BREAKING CHANGE: Node.js >= 8 required`.
+If we were to push that feature on `master`/`main` and release it, the new version would require Node.js 8 or higher as the release would also contain the commit `feat: drop Node.js 6 support \n\n BREAKING CHANGE: Node.js >= 8 required`.
 
 Instead, we create the branch `1.x` from the tag `v1.0.0` with the command `git checkout -b 1.x v1.0.0` and we commit that feature with the message `feat: a feature` to the branch `1.x`. When pushing that commit, **semantic-release** will release the version `1.1.0` on the dist-tag `@release-1.x` so users who can't migrate to Node.js 8 or higher can benefit from it.
 
@@ -85,13 +85,13 @@ The Git history of the repository is now:
 |  *  | Merge branch 1.0.x into 1.x # => v1.1.1 on @1.x
 ```
 
-## Porting bug fixes and features to master
+## Porting bug fixes and features to master/main
 
 Finally we want to make both our feature and bug fix available to users using the `@latest` dist-tag.
 
-To do so we need to merge the changes made on `1.x` (the commits `feat: a feature` and `fix: a fix`) into `master`. As `1.x` and `master` branches have diverged, this merge might require to resolve conflicts.
+To do so we need to merge the changes made on `1.x` (the commits `feat: a feature` and `fix: a fix`) into `master`/`main`. As `1.x` and `master`/`main` branches have diverged, this merge might require to resolve conflicts.
 
-Once the conflicts are resolved and the merge commit is pushed to `master`, **semantic-release** will release the version `2.1.0` on the dist-tag `@latest` which now contains the breaking change feature, the feature and the bug fix.
+Once the conflicts are resolved and the merge commit is pushed to `master` or `main`, **semantic-release** will release the version `2.1.0` on the dist-tag `@latest` which now contains the breaking change feature, the feature and the bug fix.
 
 The Git history of the repository is now:
 
@@ -105,14 +105,14 @@ The Git history of the repository is now:
 |  | /|
 |  *  | Merge branch 1.0.x into 1.x # => v1.1.1 on @1.x
 | /|  |
-*  |  | Merge branch 1.x into master # => v2.1.0 on @latest
+*  |  | Merge branch 1.x into master/main # => v2.1.0 on @latest
 ```
 
 ## Releasing a bug fix for version 2.1.0 users
 
 One of our users using the version `2.1.0` version reports a bug.
 
-We can simply commit the bug fix with the message `fix: another fix` to `master`. When pushing that commit, **semantic-release** will release the version `2.1.1` on the dist-tag `@latest`.
+We can simply commit the bug fix with the message `fix: another fix` to `master`/`main`. When pushing that commit, **semantic-release** will release the version `2.1.1` on the dist-tag `@latest`.
 
 The Git history of the repository is now:
 
@@ -126,15 +126,15 @@ The Git history of the repository is now:
 |  | /|
 |  *  | Merge branch 1.0.x into 1.x # => v1.1.1 on @1.x
 | /|  |
-*  |  | Merge branch 1.x into master # => v2.1.0 on @latest
+*  |  | Merge branch 1.x into master/main # => v2.1.0 on @latest
 *  |  | fix: another fix # => v2.1.1 on @latest
 ```
 
-## Porting a bug fix from master to 1.x
+## Porting a bug fix from master/main to 1.x
 
 The bug fix `fix: another fix` also affects version `1.1.1` users, so we want to port it to the `1.x` branch.
 
-To do so we need to cherry pick our fix commit made on `master` (`fix: another fix`) into `1.x` with `git checkout 1.x && git cherry-pick <sha of fix: another fix>`. As `master` and `1.x` branches have diverged, the cherry picking might require to resolve conflicts.
+To do so we need to cherry pick our fix commit made on `master`/`main` (`fix: another fix`) into `1.x` with `git checkout 1.x && git cherry-pick <sha of fix: another fix>`. As `master`/`main` and `1.x` branches have diverged, the cherry picking might require to resolve conflicts.
 
 Once the conflicts are resolved and the commit is pushed to `1.x`, **semantic-release** will release the version `1.1.2` on the dist-tag `@release-1.x` which contains `feat: a feature`, `fix: a fix` and `fix: another fix` but not `feat: drop Node.js 6 support \n\n BREAKING CHANGE: Node.js >= 8 required`.
 
@@ -150,7 +150,7 @@ The Git history of the repository is now:
 |  | /|
 |  *  | Merge branch 1.0.x into 1.x # => v1.1.1 on @1.x
 | /|  |
-*  |  | Merge branch 1.x into master # => v2.1.0 on @latest
+*  |  | Merge branch 1.x into master/main # => v2.1.0 on @latest
 *  |  | fix: another fix # => v2.1.1 on @latest
 |  |  |
 |  *  | fix: another fix # => v1.1.2 on @1.x