diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 19a1402eb..85b7acd3e 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -202,7 +202,7 @@ PR are always welcome, even if they only contain small fixes like typos or a few Please submit a PR broken down into small changes bit by bit. A PR consisting of a lot features and code changes may be hard to review. It is recommended to submit PRs in an incremental fashion. -Note: If you split your pull request to small changes, please make sure any of the changes goes to master will not break anything. Otherwise, it can not be merged until this feature complete. +Note: If you split your pull request to small changes, please make sure any of the changes goes to `main` will not break anything. Otherwise, it can not be merged until this feature complete. ### Fork and clone @@ -221,21 +221,21 @@ user={your github profile name} Both `$working_dir` and `$user` are mentioned in the figure above. ### Branch -Changes should be made on your own fork in a new branch. The branch should be named `XXX-description` where XXX is the number of the issue. PR should be rebased on top of master without multiple branches mixed into the PR. If your PR do not merge cleanly, use commands listed below to get it up to date. +Changes should be made on your own fork in a new branch. The branch should be named `XXX-description` where XXX is the number of the issue. PR should be rebased on top of `main` without multiple branches mixed into the PR. If your PR do not merge cleanly, use commands listed below to get it up to date. ``` #goharbor is the origin upstream cd $working_dir/harbor git fetch goharbor -git checkout master -git rebase goharbor/master +git checkout main +git rebase goharbor/main ``` -Branch from the updated `master` branch: +Branch from the updated `main` branch: ``` -git checkout -b my_feature master +git checkout -b my_feature main ``` ### Develop, Build and Test @@ -281,11 +281,11 @@ As now Harbor uses `controller/manager/dao` programming model, we suggest to use ### Keep sync with upstream -Once your branch gets out of sync with the goharbor/master branch, use the following commands to update: +Once your branch gets out of sync with the goharbor/main branch, use the following commands to update: ```bash git checkout my_feature git fetch -a -git rebase goharbor/master +git rebase goharbor/main ``` diff --git a/RELEASES.md b/RELEASES.md index cb25e47e8..350ee7bee 100644 --- a/RELEASES.md +++ b/RELEASES.md @@ -5,7 +5,7 @@ This document describes the versioning and release process of Harbor. This docum Harbor releases will be versioned using dotted triples, similar to [Semantic Version](http://semver.org/). For this specific document, we will refer to the respective components of this triple as `..`. The version number may have additional information, such as "-rc1,-rc2,-rc3" to mark release candidate builds for earlier access. Such releases will be considered as "pre-releases". ### Major and Minor Releases -Major and minor releases of Harbor will be branched from master when the release reaches to `RC(release candidate)` state. The branch format should follow `release-..0`. For example, once the release `v1.0.0` reaches to RC, a branch will be created with the format `release-1.0.0`. When the release reaches to `GA(General Available)` state, The tag with format `v..` and should be made with command `git tag -s v..`. The release cadence is around 3 months, might be adjusted based on open source event, but will communicate it clearly. +Major and minor releases of Harbor will be branched from `main` when the release reaches to `RC(release candidate)` state. The branch format should follow `release-..0`. For example, once the release `v1.0.0` reaches to RC, a branch will be created with the format `release-1.0.0`. When the release reaches to `GA(General Available)` state, The tag with format `v..` and should be made with command `git tag -s v..`. The release cadence is around 3 months, might be adjusted based on open source event, but will communicate it clearly. ### Patch releases Patch releases are based on the major/minor release branch, the release cadence for patch release of recent minor release is one month to solve critical community and security issues. The cadence for patch release of recent minus two minor releases are on-demand driven based on the severity of the issue to be fixed.