docs(): docs reference main instead of master (ionic-team#24216)

.github/COMPONENT-GUIDE.md

@@ -356,9 +356,9 @@ ion-ripple-effect {
 
 ### Example Components
 
-- [ion-button](https://github.com/ionic-team/ionic/tree/master/core/src/components/button)
-- [ion-back-button](https://github.com/ionic-team/ionic/tree/master/core/src/components/back-button)
-- [ion-menu-button](https://github.com/ionic-team/ionic/tree/master/core/src/components/menu-button)
+- [ion-button](https://github.com/ionic-team/ionic/tree/main/core/src/components/button)
+- [ion-back-button](https://github.com/ionic-team/ionic/tree/main/core/src/components/back-button)
+- [ion-menu-button](https://github.com/ionic-team/ionic/tree/main/core/src/components/menu-button)
 
 ### References
 
@@ -372,7 +372,7 @@ ion-ripple-effect {
 
 #### Example Components
 
-- [ion-checkbox](https://github.com/ionic-team/ionic/tree/master/core/src/components/checkbox)
+- [ion-checkbox](https://github.com/ionic-team/ionic/tree/main/core/src/components/checkbox)
 
 #### VoiceOver
 
@@ -498,7 +498,7 @@ This is a compromise we have to make in order for it to work with the other scre
 
 #### Example Components
 
-- [ion-toggle](https://github.com/ionic-team/ionic/tree/master/core/src/components/toggle)
+- [ion-toggle](https://github.com/ionic-team/ionic/tree/main/core/src/components/toggle)
 
 #### Voiceover
 
@@ -631,11 +631,11 @@ Certain components can render an `<a>` or a `<button>` depending on the presence
 
 ### Example Components
 
-- [ion-button](https://github.com/ionic-team/ionic/tree/master/core/src/components/button)
-- [ion-card](https://github.com/ionic-team/ionic/tree/master/core/src/components/card)
-- [ion-fab-button](https://github.com/ionic-team/ionic/tree/master/core/src/components/fab-button)
-- [ion-item-option](https://github.com/ionic-team/ionic/tree/master/core/src/components/item-option)
-- [ion-item](https://github.com/ionic-team/ionic/tree/master/core/src/components/item)
+- [ion-button](https://github.com/ionic-team/ionic/tree/main/core/src/components/button)
+- [ion-card](https://github.com/ionic-team/ionic/tree/main/core/src/components/card)
+- [ion-fab-button](https://github.com/ionic-team/ionic/tree/main/core/src/components/fab-button)
+- [ion-item-option](https://github.com/ionic-team/ionic/tree/main/core/src/components/item-option)
+- [ion-item](https://github.com/ionic-team/ionic/tree/main/core/src/components/item)
 
 ### Component Structure
 

.github/CONTRIBUTING.md

@@ -36,7 +36,7 @@ Thanks for your interest in contributing to the Ionic Framework! :tada:
 
 ## Contributing Etiquette
 
-Please see our [Contributor Code of Conduct](https://github.com/ionic-team/ionic/blob/master/CODE_OF_CONDUCT.md) for information on our rules of conduct.
+Please see our [Contributor Code of Conduct](https://github.com/ionic-team/ionic/blob/main/CODE_OF_CONDUCT.md) for information on our rules of conduct.
 
 
 ## Creating an Issue
@@ -93,7 +93,7 @@ Without a reliable code reproduction, it is unlikely we will be able to resolve
 1. [Download the installer](https://nodejs.org/) for the LTS version of Node.js. This is the best way to also [install npm](https://blog.npmjs.org/post/85484771375/how-to-install-npm#_=_).
 2. Fork this repository.
 3. Clone your fork.
-4. Create a new branch from master for your change.
+4. Create a new branch from main for your change.
 5. Navigate into the directory of the package you wish to modify (core, angular, etc.).
 6. Run `npm install` to install dependencies for this package.
 7. Follow the steps for the specific package below.
@@ -219,14 +219,14 @@ Without a reliable code reproduction, it is unlikely we will be able to resolve
 
 ### Submit Pull Request
 
-1. [Create a new pull request](https://github.com/ionic-team/ionic/compare) with the `master` branch as the `base`. You may need to click on `compare across forks` to find your changes.
+1. [Create a new pull request](https://github.com/ionic-team/ionic/compare) with the `main` branch as the `base`. You may need to click on `compare across forks` to find your changes.
 2. See the [Creating a pull request from a fork](https://help.github.com/articles/creating-a-pull-request-from-a-fork/) GitHub help article for more information.
 3. Please fill out the provided Pull Request template to the best of your ability and include any issues that are related.
 
 
 ## Commit Message Guidelines
 
-We have very precise rules over how our git commit messages should be formatted. This leads to readable messages that are easy to follow when looking through the project history. We also use the git commit messages to generate our [changelog](https://github.com/ionic-team/ionic/blob/master/CHANGELOG.md). Our format closely resembles Angular's [commit message guidelines](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit).
+We have very precise rules over how our git commit messages should be formatted. This leads to readable messages that are easy to follow when looking through the project history. We also use the git commit messages to generate our [changelog](https://github.com/ionic-team/ionic/blob/main/CHANGELOG.md). Our format closely resembles Angular's [commit message guidelines](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit).
 
 ### Commit Message Format
 

.github/PROCESS.md

@@ -95,81 +95,81 @@ Issues with this label are not automatically closed and locked, so we manually c
 
 We have two long-living branches:
 
-- `master`: completed features, bug fixes, refactors, chores
+- `main`: completed features, bug fixes, refactors, chores
 - `stable`: the latest release
 
 The overall flow:
 
-1. Feature, refactor, and bug fix branches are created from `master`
-1. When a feature, refactor, or fix is complete it is merged into `master`
-1. A release branch is created from `master`
-1. When the release branch is done it is merged into `master` and `stable`
+1. Feature, refactor, and bug fix branches are created from `main`
+1. When a feature, refactor, or fix is complete it is merged into `main`
+1. A release branch is created from `main`
+1. When the release branch is done it is merged into `main` and `stable`
 1. If an issue in `stable` is detected a hotfix branch is created from `stable`
-1. Once the hotfix is complete it is merged to both `master` and `stable`
-1. All branches should follow the syntax of `{type}-{details}` where `{type}` is the type of branch (`hotfix`, `release`, or one of the [commit types](https://github.com/ionic-team/ionic/blob/master/.github/CONTRIBUTING.md#commit-message-format)) and `{details}` is a few hyphen separated words explaining the branch
+1. Once the hotfix is complete it is merged to both `main` and `stable`
+1. All branches should follow the syntax of `{type}-{details}` where `{type}` is the type of branch (`hotfix`, `release`, or one of the [commit types](https://github.com/ionic-team/ionic/blob/main/.github/CONTRIBUTING.md#commit-message-format)) and `{details}` is a few hyphen separated words explaining the branch
 
-### Stable and Master Branches
+### Stable and Main Branches
 
 #### Stable Branch
 
 Branches created from `stable`:
 
-The following branch should be merged back to **both** `master` and `stable`:
+The following branch should be merged back to **both** `main` and `stable`:
 
 - A `hotfix` branch (e.g. `hotfix-missing-export`): a bug fix that is fixing a regression or issue with a published release
 
 A `hotfix` branch should be the **only** branch that is created from stable.
 
-#### Master Branch
+#### Main Branch
 
-Branches created from `master`:
+Branches created from `main`:
 
-The following branches should be merged back to `master` via a pull request:
+The following branches should be merged back to `main` via a pull request:
 
 1. A feature branch (e.g. `feat-desktop-support`): an addition to the API that is not a bug fix or regression fix
 1. A bug fix branch (e.g. `fix-tab-color`): a bug fix that is not fixing a regression or issue with a published release
-1. All other types listed in the [commit message types](https://github.com/ionic-team/ionic/blob/master/.github/CONTRIBUTING.md#commit-message-format): `docs`, `style`, `refactor`, `perf`, `test`, `chore`
+1. All other types listed in the [commit message types](https://github.com/ionic-team/ionic/blob/main/.github/CONTRIBUTING.md#commit-message-format): `docs`, `style`, `refactor`, `perf`, `test`, `chore`
 
-The following branch should be merged back to **both** `master` and `stable`:
+The following branch should be merged back to **both** `main` and `stable`:
 
 1. A `release` branch (e.g. `release-4.1.x`): contains all fixes and (optionally) features that are tested and should go into the release
 
 
 ### Feature Branches
 
-Each new feature should reside in its own branch, based on the `master` branch. When a feature is complete, it should go into a pull request that gets merged back into `master`. A pull request adding a feature should be approved by two team members. Features should never interact directly with `stable`.
+Each new feature should reside in its own branch, based on the `main` branch. When a feature is complete, it should go into a pull request that gets merged back into `main`. A pull request adding a feature should be approved by two team members. Features should never interact directly with `stable`.
 
 
 ### Release Branches
 
-Once `master` has acquired enough features for a release (or a predetermined release date is approaching), fork a release branch off of `master`. Creating this branch starts the next release cycle, so no new features can be added after this point - only bug fixes, documentation generation, and other release-oriented tasks should go in this branch.
+Once `main` has acquired enough features for a release (or a predetermined release date is approaching), fork a release branch off of `main`. Creating this branch starts the next release cycle, so no new features can be added after this point - only bug fixes, documentation generation, and other release-oriented tasks should go in this branch.
 
-Once the release is ready to ship, it will get merged into `stable` and `master`, then the release branch will be deleted. It’s important to merge back into `master` because critical updates may have been added to the release branch and they need to be accessible to new features. This should be done in a pull request after review.
+Once the release is ready to ship, it will get merged into `stable` and `main`, then the release branch will be deleted. It’s important to merge back into `main` because critical updates may have been added to the release branch and they need to be accessible to new features. This should be done in a pull request after review.
 
 See the [steps for releasing](#releasing) below for detailed information on how to publish a release.
 
 ### Version Branches
 
-Once a release has shipped and the release branch has been merged into `stable` and `master` it should also be merged into its corresponding version branch. These version branches allow us to ship updates for specific versions of the framework (i.e. Lets us ship a bug fix that only affects 4.2.x).
+Once a release has shipped and the release branch has been merged into `stable` and `main` it should also be merged into its corresponding version branch. These version branches allow us to ship updates for specific versions of the framework (i.e. Lets us ship a bug fix that only affects 4.2.x).
 
 Patch releases should be merged into their corresponding version branches. For example, a `release-4.1.1` branch should be merged into the `4.1.x` version branch and a `release-5.0.1` branch should be merged into the `5.0.x` version branch.
 
-When releasing a major version such as `5.0.0 ` or a minor version such as `4.1.0` , the version branch will not exist. The version branch should be created once the release branch has been merged into `stable` and `master`. For example, when releasing `4.1.0`, the `release-4.1.0` release branch should be merged into `stable` and `master` and then the `4.1.x` version branch should be created off the latest `stable`.
+When releasing a major version such as `5.0.0 ` or a minor version such as `4.1.0` , the version branch will not exist. The version branch should be created once the release branch has been merged into `stable` and `main`. For example, when releasing `4.1.0`, the `release-4.1.0` release branch should be merged into `stable` and `main` and then the `4.1.x` version branch should be created off the latest `stable`.
 
 
 ### Hotfix Branches
 
-Maintenance or “hotfix” branches are used to quickly patch production releases. This is the only branch that should fork directly off of `stable`. As soon as the fix is complete, it should be merged into both `stable` and `master` (or the current release branch).
+Maintenance or “hotfix” branches are used to quickly patch production releases. This is the only branch that should fork directly off of `stable`. As soon as the fix is complete, it should be merged into both `stable` and `main` (or the current release branch).
 
 
 ### Examples
 
 #### Making a Change
 
-1. Create a branch from `master`.
+1. Create a branch from `main`.
 1. Make changes. Limit your changes to a "unit of work", meaning don't include irrelevant changes that may confuse and delay the change.
 1. Push changes.
-1. Create a PR with the base of `master`.
+1. Create a PR with the base of `main`.
 1. Have someone approve your change (optional right now--at your discretion).
 
  <img width="236" alt="image" src="https://user-images.githubusercontent.com/236501/47031893-913e0480-d136-11e8-9d9a-4b6297a4d7ba.png">
@@ -182,13 +182,13 @@ Maintenance or “hotfix” branches are used to quickly patch production releas
 
  <img width="192" alt="Squash and merge button" src="https://user-images.githubusercontent.com/236501/47031620-da418900-d135-11e8-91ff-e84f2478b2b3.png">
 
-1. During confirmation, rewrite the commit message using our [Commit Message Format guidelines](https://github.com/ionic-team/ionic/blob/master/.github/CONTRIBUTING.md#commit-message-format). Keep the `(#1234)` at the end; it will create a link to the PR in the commit history and `CHANGELOG.md`. This is where commits on `master` become permanent.
+1. During confirmation, rewrite the commit message using our [Commit Message Format guidelines](https://github.com/ionic-team/ionic/blob/main/.github/CONTRIBUTING.md#commit-message-format). Keep the `(#1234)` at the end; it will create a link to the PR in the commit history and `CHANGELOG.md`. This is where commits on `main` become permanent.
 
  <img width="672" alt="Squash and merge confirmation" src="https://user-images.githubusercontent.com/236501/47031753-31dff480-d136-11e8-9116-03934961bdc2.png">
 
-1. Confirm squash and merge into `master`.
+1. Confirm squash and merge into `main`.
 
-#### Updating from `master`
+#### Updating from `main`
 
 1. Pull the latest changes locally.
 1. Merge the changes, fixing any conflicts.
@@ -204,7 +204,7 @@ OR
 
 #### Hotfixes
 
-Hotfixes bypass `master` and should only be used for urgent fixes that can't wait for the next release to be ready.
+Hotfixes bypass `main` and should only be used for urgent fixes that can't wait for the next release to be ready.
 
 1. Create a branch from `stable`.
 1. Make changes.
@@ -215,21 +215,21 @@ Hotfixes bypass `master` and should only be used for urgent fixes that can't wai
 
  <img width="192" alt="Squash and merge button" src="https://user-images.githubusercontent.com/236501/47031620-da418900-d135-11e8-91ff-e84f2478b2b3.png">
 
-1. During confirmation, rewrite the commit message using our [Commit Message Format guidelines](https://github.com/ionic-team/ionic/blob/master/.github/CONTRIBUTING.md#commit-message-format). Keep the `(#1234)` at the end; it will create a link to the PR in the commit history and `CHANGELOG.md`. This is where commits on `master` become permanent.
+1. During confirmation, rewrite the commit message using our [Commit Message Format guidelines](https://github.com/ionic-team/ionic/blob/main/.github/CONTRIBUTING.md#commit-message-format). Keep the `(#1234)` at the end; it will create a link to the PR in the commit history and `CHANGELOG.md`. This is where commits on `main` become permanent.
 
  <img width="672" alt="Squash and merge confirmation" src="https://user-images.githubusercontent.com/236501/47031753-31dff480-d136-11e8-9116-03934961bdc2.png">
 
 1. Confirm squash and merge into `stable`.
 1. CI builds `stable`, performing the release.
-1. Create a PR to merge `stable` into `master`.
+1. Create a PR to merge `stable` into `main`.
 1. Click **Merge pull request**. Use the dropdown to select this option if necessary.
 
  <img width="191" alt="Merge pull request button" src="https://user-images.githubusercontent.com/236501/47032669-8be1b980-d138-11e8-9a90-d1518c223184.png">
 
 
 ## Releasing
 
-1. Create the release branch from `master`, for example: `release-4.5.0`.
+1. Create the release branch from `main`, for example: `release-4.5.0`.
 
 1. For major or minor releases, create a version branch based off the latest version branch. For example, if releasing 4.5.0, create a branch called `4.5.x` based off `4.4.x`.
 
@@ -244,7 +244,7 @@ Hotfixes bypass `master` and should only be used for urgent fixes that can't wai
 1. Run `npm run release.prepare`
  - Select the version based on the type of commits and the [Ionic Versioning](https://ionicframework.com/docs/intro/versioning)
  - After the process completes, verify the version number in all packages (`core`, `docs`, `angular`)
- - Verify the changelog commits are accurate and follow the [proper format]((https://github.com/ionic-team/ionic/blob/master/.github/CONTRIBUTING.md#commit-message-format))
+ - Verify the changelog commits are accurate and follow the [proper format]((https://github.com/ionic-team/ionic/blob/main/.github/CONTRIBUTING.md#commit-message-format))
  - For major or minor releases, ensure that the version number has an associated title (for example: `4.5.0 Boron`)
  - Commit these changes with the version number as the message, e.g. `git commit -m "4.5.0"`
 
@@ -258,4 +258,4 @@ Hotfixes bypass `master` and should only be used for urgent fixes that can't wai
 
 1. Rewrite the commit message to `merge release-[VERSION]` with the proper release branch. For example, if this release is for `4.5.0`, the message would be `merge release-4.5.0`.
 
-1. Submit a pull request from the release branch into `master`. Merge this pull request using the same commit format in the last step, to ensure any changes made on the release branch get added to future releases.
+1. Submit a pull request from the release branch into `main`. Merge this pull request using the same commit format in the last step, to ensure any changes made on the release branch get added to future releases.

.scripts/release.js

@@ -127,7 +127,7 @@ async function publishGithub(version, gitTag, changelog, npmTag) {
  let branch = await execa.stdout('git', ['symbolic-ref', '--short', 'HEAD']);
 
  if (!branch) {
- branch = 'master';
+ branch = 'main';
  }
 
  await octokit.repos.createRelease({

README.md

@@ -30,11 +30,11 @@ an [issue](https://github.com/ionic-team/ionic/issues/new) on this repository.
 ### Contributing
 
 Thanks for your interest in contributing! Read up on our guidelines for
-[contributing](https://github.com/ionic-team/ionic/blob/master/.github/CONTRIBUTING.md)
+[contributing](https://github.com/ionic-team/ionic/blob/main/.github/CONTRIBUTING.md)
 and then look through our issues with a [help wanted](https://github.com/ionic-team/ionic/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22)
 label.
 
-Please note that this project is released with a [Contributor Code of Conduct](https://github.com/ionic-team/ionic/blob/master/CODE_OF_CONDUCT.md). By participating in this project you agree to abide by its terms.
+Please note that this project is released with a [Contributor Code of Conduct](https://github.com/ionic-team/ionic/blob/main/CODE_OF_CONDUCT.md). By participating in this project you agree to abide by its terms.
 
 
 ### Examples