From 4bf2eb838a32275433793e0692e32a373685f41e Mon Sep 17 00:00:00 2001 From: Lucas Holmquist Date: Wed, 12 Aug 2020 19:00:02 -0400 Subject: [PATCH] chore: Update references of master to main (#316) Signed-off-by: Lucas Holmquist --- .github/pull-request-template.md | 4 +-- .github/workflows/nodejs-ci-action.yml | 4 +-- CONTRIBUTING.md | 2 +- README.md | 4 +-- RELEASE_GUIDELINES.md | 8 +++--- maintainer_guidelines.md | 6 ++--- pr_guidelines.md | 36 ++++++++++++++------------ 7 files changed, 33 insertions(+), 31 deletions(-) diff --git a/.github/pull-request-template.md b/.github/pull-request-template.md index e704383..5fe5aa7 100644 --- a/.github/pull-request-template.md +++ b/.github/pull-request-template.md @@ -1,12 +1,12 @@ ## Proposed Changes -- +- - - diff --git a/.github/workflows/nodejs-ci-action.yml b/.github/workflows/nodejs-ci-action.yml index c1de892..732a93c 100644 --- a/.github/workflows/nodejs-ci-action.yml +++ b/.github/workflows/nodejs-ci-action.yml @@ -5,9 +5,9 @@ name: Node.js CI on: push: - branches: [ master ] + branches: [ main ] pull_request: - branches: [ master ] + branches: [ main ] jobs: build: diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 4e2a4d4..74e2fc7 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -38,4 +38,4 @@ check your code style for linting errors without running tests, you can just run `npm run lint`. If there are errors, you can usually fix them automatically by running `npm run fix`. -Linting rules are declared in [.eslintrc](https://github.com/cloudevents/sdk-javascript/blob/master/.eslintrc). +Linting rules are declared in [.eslintrc](https://github.com/cloudevents/sdk-javascript/blob/main/.eslintrc). diff --git a/README.md b/README.md index 8595a40..65a9511 100644 --- a/README.md +++ b/README.md @@ -110,7 +110,7 @@ const ce2 = ce.cloneWith({extension: "Value"}); ### Example Applications There are a few trivial example applications in -[the examples folder](https://github.com/cloudevents/sdk-javascript/tree/master/examples). +[the examples folder](https://github.com/cloudevents/sdk-javascript/tree/main/examples). There you will find Express.js, TypeScript and Websocket examples. ## Supported specification features @@ -150,7 +150,7 @@ There you will find Express.js, TypeScript and Websocket examples. ## Contributing We love contributions from the community! Please check the -[Contributor's Guide](https://github.com/cloudevents/sdk-javascript/blob/master/CONTRIBUTING.md) +[Contributor's Guide](https://github.com/cloudevents/sdk-javascript/blob/main/CONTRIBUTING.md) for information on how to get involved. Each SDK may have its own unique processes, tooling and guidelines, common diff --git a/RELEASE_GUIDELINES.md b/RELEASE_GUIDELINES.md index ae29e11..1c920c1 100644 --- a/RELEASE_GUIDELINES.md +++ b/RELEASE_GUIDELINES.md @@ -6,15 +6,15 @@ To prepare for a new release, create a [new issue](https://github.com/cloudevent For example: "Proposal for 3.2.0 release", or something similar. If you are not sure which version is the next version to be released, you can run `npm run release -- --dry-run` to find out what the next version will be. -The body of the issue should be the commits that will be part of the release. This can be easily accomplished by running a git log command with a defined **range**. This range should start at the most recent version tag and end at the latest commit in the master branch. +The body of the issue should be the commits that will be part of the release. This can be easily accomplished by running a git log command with a defined **range**. This range should start at the most recent version tag and end at the latest commit in the main branch. For example: ``` -git log v3.0.1..upstream/master --oneline +git log v3.0.1..upstream/main --oneline ``` -This will output all the commits from the 3.0.1 tag to the latest commits in the remote upstream/master branch. +This will output all the commits from the 3.0.1 tag to the latest commits in the remote upstream/main branch. This output should be pasted into the issue as normal text. This will allow Github to magically turn all commit hashes and PR/Issues numbers to links. @@ -37,7 +37,7 @@ npm run release This will update the CHANGELOG.md and create a new tag based on the version. This can then be pushed upstream by doing: ``` -git push upstream master --follow-tags +git push upstream main --follow-tags ``` ### Create the release on GitHub diff --git a/maintainer_guidelines.md b/maintainer_guidelines.md index 49a438c..b55677a 100644 --- a/maintainer_guidelines.md +++ b/maintainer_guidelines.md @@ -26,15 +26,15 @@ When landing pull requests, be sure to check the first line uses an appropriate ## Branch Management -The `master` branch is the bleeding edge. New major versions of the module +The `main` branch is the bleeding edge. New major versions of the module are cut from this branch and tagged. If you intend to submit a pull request -you should use `master HEAD` as your starting point. +you should use `main HEAD` as your starting point. Each major release will result in a new branch and tag. For example, the release of version 1.0.0 of the module will result in a `v1.0.0` tag on the release commit, and a new branch `v1.x.y` for subsequent minor and patch level releases of that major version. However, development will continue -apace on `master` for the next major version - e.g. 2.0.0. Version branches +apace on `main` for the next major version - e.g. 2.0.0. Version branches are only created for each major version. Minor and patch level releases are simply tagged. diff --git a/pr_guidelines.md b/pr_guidelines.md index 440674c..7a46545 100644 --- a/pr_guidelines.md +++ b/pr_guidelines.md @@ -5,13 +5,15 @@ a pull request in this repository. We hope it will help you have an easy time managing your work and a positive, satisfying experience when contributing your code. Thanks for getting involved! :rocket: -* [Getting Started](#getting-started) -* [Branches](#branches) -* [Commit Messages](#commit-messages) -* [Staying current with master](#staying-current-with-master) -* [Style Guide](#style-guide) -* [Submitting and Updating a Pull Request](#submitting-and-updating-a-pull-request) -* [Congratulations!](#congratulations) +- [Pull Request Guidelines](#pull-request-guidelines) + - [Getting Started](#getting-started) + - [Branches](#branches) + - [Commit Messages](#commit-messages) + - [Signing your commits](#signing-your-commits) + - [Staying Current with `main`](#staying-current-with-main) + - [Style Guide](#style-guide) + - [Submitting and Updating Your Pull Request](#submitting-and-updating-your-pull-request) + - [Congratulations!](#congratulations) ## Getting Started @@ -35,7 +37,7 @@ you might create a branch named `48-fix-http-agent-error`. ```console git fetch upstream -git reset --hard upstream/master +git reset --hard upstream/main git checkout FETCH_HEAD git checkout -b 48-fix-http-agent-error ``` @@ -102,19 +104,19 @@ Date: Thu Feb 2 11:41:15 2018 -0800 Notice the `Author` and `Signed-off-by` lines match. If they don't your PR will be rejected by the automated DCO check. -## Staying Current with `master` +## Staying Current with `main` -As you are working on your branch, changes may happen on `master`. Before +As you are working on your branch, changes may happen on `main`. Before submitting your pull request, be sure that your branch has been updated with the latest commits. ```console git fetch upstream -git rebase upstream/master +git rebase upstream/main ``` This may cause conflicts if the files you are changing on your branch are -also changed on master. Error messages from `git` will indicate if conflicts +also changed on main. Error messages from `git` will indicate if conflicts exist and what files need attention. Resolve the conflicts in each file, then continue with the rebase with `git rebase --continue`. @@ -134,22 +136,22 @@ check your code style for linting errors without running tests, you can just run `npm run lint`. If there are errors, you can usually fix them automatically by running `npm run fix`. -Linting rules are declared in [.eslintrc](https://github.com/cloudevents/sdk-javascript/blob/master/.eslintrc). +Linting rules are declared in [.eslintrc](https://github.com/cloudevents/sdk-javascript/blob/main/.eslintrc). ## Submitting and Updating Your Pull Request Before submitting a pull request, you should make sure that all of the tests successfully pass by running `npm test`. -Once you have sent your pull request, `master` may continue to evolve -before your pull request has landed. If there are any commits on `master` +Once you have sent your pull request, `main` may continue to evolve +before your pull request has landed. If there are any commits on `main` that conflict with your changes, you may need to update your branch with these changes before the pull request can land. Resolve conflicts the same way as before. ```console git fetch upstream -git rebase upstream/master +git rebase upstream/main # fix any potential conflicts git push -f origin 48-fix-http-agent-error ``` @@ -166,7 +168,7 @@ for details. ```console git commit -m "fixup: fix typo" -git rebase -i upstream/master # follow git instructions +git rebase -i upstream/main # follow git instructions ``` Once you have rebased your commits, you can force push to your fork as before.