Upstream
/
harbor
mirror of https://github.com/goharbor/harbor.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update RELEASE and CONTRIBUTING with main instead of master (#17983) 

Signed-off-by: OrlinVasilev <ovasilev@vmware.com>

Signed-off-by: OrlinVasilev <ovasilev@vmware.com>
Co-authored-by: OrlinVasilev <ovasilev@vmware.com>
This commit is contained in:
Orlix 2022-12-14 10:11:34 +02:00 committed by GitHub
parent b0a30b9a2f
commit b7e4e90427
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
CONTRIBUTING.md
View File

@ -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
```

2
RELEASES.md
View File

@ -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 `<major>.<minor>.<patch>`. 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-<major>.<minor>.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<major>.<minor>.<patch>` and should be made with command `git tag -s v<major>.<minor>.<patch>`. 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-<major>.<minor>.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<major>.<minor>.<patch>` and should be made with command `git tag -s v<major>.<minor>.<patch>`. 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.