chore: Update references of master to main (#316)
Signed-off-by: Lucas Holmquist <lholmqui@redhat.com>
This commit is contained in:
Lucas Holmquist
GitHub
parent
b5cf8865b9
commit
4bf2eb838a
|
|
@ -1,12 +1,12 @@
|
|||
<!-- General PR guidelines:
|
||||
|
||||
Most PRs should be opened against the master branch.
|
||||
Most PRs should be opened against the main branch.
|
||||
|
||||
-->
|
||||
|
||||
## Proposed Changes
|
||||
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
|
||||
|
|
|
|||
|
|
@ -5,9 +5,9 @@ name: Node.js CI
|
|||
|
||||
on:
|
||||
push:
|
||||
branches: [ master ]
|
||||
branches: [ main ]
|
||||
pull_request:
|
||||
branches: [ master ]
|
||||
branches: [ main ]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
Loading…
Reference in New Issue