crossplane
/
docs
mirror of https://github.com/crossplane/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

docs snapshot for crossplane version `master`

This commit is contained in:
Crossplane 2021-02-09 01:25:44 +00:00
parent 10189390d1
commit 9d79e92f04
1 changed files with 52 additions and 55 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

101
docs/master/contributing/release-process.md
View File

@ -17,10 +17,10 @@ with a very high level sequential overview for how to run the release process.
These steps apply to all Crossplane projects, all of which utilize [Github These steps apply to all Crossplane projects, all of which utilize [Github
Actions](https://github.com/features/actions) for pipelines. Actions](https://github.com/features/actions) for pipelines.
1. **feature freeze**: Merge all completed features into master branches of all 1. **feature freeze**: Merge all completed features into main development branch
repos to begin "feature freeze" period. of all repos to begin "feature freeze" period.
1. **pin dependencies**: Update the go module in master to depend on stable 1. **pin dependencies**: Update the go module on main development branch to
versions of dependencies if needed. depend on stable versions of dependencies if needed.
1. **branch repo**: Create a new release branch using the GitHub UI for the 1. **branch repo**: Create a new release branch using the GitHub UI for the
repo. repo.
1. **release branch prep**: Make any release-specific updates on the release 1. **release branch prep**: Make any release-specific updates on the release
@ -29,8 +29,8 @@ Actions](https://github.com/features/actions) for pipelines.
desired version (e.g. `v0.14.0`). desired version (e.g. `v0.14.0`).
1. **build/publish**: Run the `CI` action on the release branch with the version 1. **build/publish**: Run the `CI` action on the release branch with the version
that was just tagged. that was just tagged.
1. **tag next pre-release**: Run the `tag` action on the `master` branch with 1. **tag next pre-release**: Run the `tag` action on the main development branch
the `rc.0` for the next release (e.g. `v0.15.0-rc.0`). with the `rc.0` for the next release (e.g. `v0.15.0-rc.0`).
1. **verify**: Verify all artifacts have been published successfully, perform 1. **verify**: Verify all artifacts have been published successfully, perform
sanity testing. sanity testing.
1. **promote**: Run the `Promote` action to promote release to desired 1. **promote**: Run the `Promote` action to promote release to desired
@ -51,12 +51,12 @@ freeze period, the following conditions should be met:
* All expected features should be * All expected features should be
["complete"](https://github.com/crossplane/crossplane/blob/master/design/one-pager-definition-of-done.md) ["complete"](https://github.com/crossplane/crossplane/blob/master/design/one-pager-definition-of-done.md)
and merged into master. This includes user guides, examples, API and merged into main development branch. This includes user guides, examples,
documentation, and test updates. API documentation, and test updates.
* All issues in the * All issues in the
[milestone](https://github.com/crossplane/crossplane/milestones) should be [milestone](https://github.com/crossplane/crossplane/milestones) should be
closed closed
* Sanity testing has been performed on `master` * Sanity testing has been performed on main development branch
### Pin Dependencies ### Pin Dependencies
@ -84,10 +84,10 @@ settings](https://github.com/crossplane/crossplane/settings/branches).
At this point, the `HEAD` commit in the release branch will be our release At this point, the `HEAD` commit in the release branch will be our release
candidate. The build pipeline will automatically be started due to the create candidate. The build pipeline will automatically be started due to the create
branch event, so we can start to perform testing on this build. Note that it branch event, so we can start to perform testing on this build. Note that it
should be the exact same as what is currently in `master` since they are using should be the exact same as what is currently in main development branch since
the same commit and have the same tag. Also note that this is not the official they are using the same commit and have the same tag. Also note that this is not
release build since we have not made the official release tag yet (e.g. the official release build since we have not made the official release tag yet
`v0.5.0`). (e.g. `v0.5.0`).
### Release Branch Prep ### Release Branch Prep
@ -101,7 +101,7 @@ examples to point to the new versions that we will be releasing soon.
* Documentation, such as pinning * Documentation, such as pinning
[snippet](https://github.com/crossplane/crossplane/blob/release-0.14/docs/snippets) [snippet](https://github.com/crossplane/crossplane/blob/release-0.14/docs/snippets)
links to the current release branch. links to the current release branch.
* searching for `master` will help a lot here * searching for `:v` will help a lot here
#### Bug Fixes in Release Branch #### Bug Fixes in Release Branch
@ -109,14 +109,15 @@ During our testing of the release candidate, we may find issues or bugs that we
triage and decide we want to fix before the release goes out. In order to fix a triage and decide we want to fix before the release goes out. In order to fix a
bug in the release branch, the following process is recommended: bug in the release branch, the following process is recommended:
1. Make the bug fix into `master` first through the normal PR process 1. Make the bug fix into main development branch first through the normal PR
1. If the applicable code has already been removed from `master` then simply process
fix the bug directly in the release branch by opening a PR directly 1. If the applicable code has already been removed from the main development
against the release branch branch then simply fix the bug directly in the release branch by opening
a PR directly against the release branch
1. Backport the fix by performing a cherry-pick of the fix's commit hash 1. Backport the fix by performing a cherry-pick of the fix's commit hash
(**not** the merge commit) from `master` into the release branch. For (**not** the merge commit) from main development branch into the release
example, to backport a fix from master to `v0.5.0`, something like the branch. For example, to backport a fix from the main development branch to
following should be used: `v0.5.0`, something like the following should be used:
```console ```console
git fetch --all git fetch --all
@ -169,38 +170,39 @@ For crossplane/crossplane:
### Tag Next Pre-release ### Tag Next Pre-release
The next step is to create the pre-release tag for the `HEAD` commit in The next step is to create the pre-release tag for the `HEAD` commit in main
`master`. This tag serves as an indication of when the release was branched development branch. This tag serves as an indication of when the release was
from master and is also important for generating future versions of `master` branched from the main development branch and is also important for generating
builds since that [versioning future versions of the main development branch builds since that [versioning
process](https://github.com/upbound/build/blob/master/makelib/common.mk#L182-L196) process](https://github.com/upbound/build/blob/master/makelib/common.mk#L182-L196)
is based on `git describe --tags`. is based on `git describe --tags`.
> NOTE: the `build` submodule uses the latest tag by timestamp on the branch > NOTE: the `build` submodule uses the latest tag by timestamp on the branch
> which the commit it is building resides on. If there were no prep commits made > which the commit it is building resides on. If there were no prep commits made
> on the release branch, then its `HEAD` is even with `master` (i.e. the stable > on the release branch, then its `HEAD` is even with the main development
> tag and the next pre-release tag will be on the same commit). This means that > branch (i.e. the stable tag and the next pre-release tag will be on the same
> we must tag the pre-release version _after_ the stable version to ensure > commit). This means that we must tag the pre-release version _after_ the
> subsequent builds use the next pre-release tag as their base. If there are > stable version to ensure subsequent builds use the next pre-release tag as
> additional commits on the release branch before the stable tag is created, > their base. If there are additional commits on the release branch before the
> then the pre-release tag could be created first. > stable tag is created, then the pre-release tag could be created first.
To accomplish this, run the `Tag` action for the repo on the `master` branch. To accomplish this, run the `Tag` action for the repo on the main development
You will be prompted to enter the `version` for the tag. Since this tag will branch branch. You will be prompted to enter the `version` for the tag. Since
essentially be the start of pre-releases working towards the **next** version, this tag will essentially be the start of pre-releases working towards the
the `version` should be the **next** release number, plus a trailing tag to **next** version, the `version` should be the **next** release number, plus a
indicate it is a pre-release. The current convention is to use `*-rc.0`. For trailing tag to indicate it is a pre-release. The current convention is to use
example, when we are releasing the `v0.9.0` release and we are ready for master `*-rc.0`. For example, when we are releasing the `v0.9.0` release and we are
to start working towards the **next** release of `v0.10.0`, we would make the ready for the main development branch to start working towards the **next**
tag `v0.10.0-rc.0` release of `v0.10.0`, we would make the tag `v0.10.0-rc.0`
After the tag action has succeeded, verify in the [GitHub After the tag action has succeeded, verify in the [GitHub
UI](https://github.com/crossplane/crossplane/tags) that the tag was successfully UI](https://github.com/crossplane/crossplane/tags) that the tag was successfully
applied to the correct commit. applied to the correct commit.
The `master` branch can now be opened for new features since we have a safe The main development branch can now be opened for new features since we have a
release branch to continue bug fixes and improvements for the release itself. safe release branch to continue bug fixes and improvements for the release
Essentially, `master` is free to now diverge from the release branch. itself. Essentially, the main development branch is free to now diverge from the
release branch.
### Promote ### Promote
@ -210,14 +212,9 @@ This is a very quick pipeline that doesn't rebuild anything, it simply makes
metadata changes to the published release to also include the release in the metadata changes to the published release to also include the release in the
channel of your choice. channel of your choice.
Currently, we only support the `master` and `alpha` channels.
Run the `Promote` action on the release branch and input the version you would Run the `Promote` action on the release branch and input the version you would
like to promote (e.g. `v0.5.0`) and the channel you'd like to promote it to. like to promote (e.g. `v0.5.0`) and the channel you'd like to promote it to.
* Run `Promote` action for `master` channel on release branch
* Run `Promote` action for `alpha` channel on release branch
After the `Promote` actions have succeeded, verify on DockerHub and the Helm After the `Promote` actions have succeeded, verify on DockerHub and the Helm
chart repository that the release has been promoted to the right channels. chart repository that the release has been promoted to the right channels.
@ -251,14 +248,14 @@ release branch, we do **not** create a new release branch for a patch release.
The basic flow is **very** similar to a normal release, but with a few less The basic flow is **very** similar to a normal release, but with a few less
steps. Please refer to details for each step in the sections above. steps. Please refer to details for each step in the sections above.
* Fix any bugs in `master` first and then `cherry-pick -x` to the release branch * Fix any bugs in the main development branch first and then `cherry-pick -x` to
* If `master` has already removed the relevant code then make your fix the release branch
directly in the release branch * If main development branch has already removed the relevant code then make
your fix directly in the release branch
* After all testing on the release branch look good and any docs/tests have been * After all testing on the release branch look good and any docs/tests have been
updated with the new version number, run the `Tag` action on the release updated with the new version number, run the `Tag` action on the release
branch with the new patch version (e.g. `v0.5.1`) branch with the new patch version (e.g. `v0.5.1`)
* Run the normal `CI` action on the release branch to build and publish the * Run the normal `CI` action on the release branch to build and publish the
release release
* Publish release notes * Publish release notes
* Run `Promote` action to promote the patch release to the `master` and `alpha` * Run `Promote` action to promote the patch release to the appropriate channels
channels