{"id":19144186,"url":"https://github.com/crossplane/release","last_synced_at":"2026-06-11T06:30:17.493Z","repository":{"id":221150037,"uuid":"739146157","full_name":"crossplane/release","owner":"crossplane","description":"Crossplane release management things","archived":false,"fork":false,"pushed_at":"2024-12-20T20:59:23.000Z","size":46,"stargazers_count":2,"open_issues_count":1,"forks_count":5,"subscribers_count":6,"default_branch":"main","last_synced_at":"2025-01-03T15:46:12.096Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/crossplane.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2024-01-04T22:01:51.000Z","updated_at":"2024-12-20T20:59:27.000Z","dependencies_parsed_at":"2024-02-06T14:10:39.053Z","dependency_job_id":"9429446a-8298-48b5-a249-64247b9734ec","html_url":"https://github.com/crossplane/release","commit_stats":null,"previous_names":["crossplane/release"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/crossplane%2Frelease","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/crossplane%2Frelease/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/crossplane%2Frelease/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/crossplane%2Frelease/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/crossplane","download_url":"https://codeload.github.com/crossplane/release/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":240225012,"owners_count":19767841,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-09T07:34:02.837Z","updated_at":"2026-06-11T06:30:17.443Z","avatar_url":"https://github.com/crossplane.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# Crossplane Release Process\n\nThis document is meant to be a complete end-to-end guide for how to release new\nversions of software for Crossplane and its related projects.\n\n## tl;dr Process Overview\n\nAll the details are available in the sections below, but we'll start this guide\nwith a very high level sequential overview for how to run the release process.\nThese steps apply to all Crossplane projects, all of which utilize [Github\nActions](https://github.com/features/actions) for pipelines.\n\n1. **feature freeze**: Merge all completed features into main development branch\n   of all repos to begin \"feature freeze\" period.\n1. **pin dependencies**: Update the go module on main development branch to\n   depend on stable versions of dependencies if needed.\n1. **branch repo**: Create a new release branch using the GitHub UI for the\n   repo.\n1. **release branch prep**: Make any release-specific updates on the release\n   branch (typically documentation).\n1. **tag release**: Run the `Tag` action on the _release branch_ with the\n   desired version (e.g. `v0.14.0`).\n1. **build/publish**: Run the `CI` and `Configurations` action on the release\n   branch with the version that was just tagged.\n1. **tag next pre-release**: Run the `tag` action on the main development branch\n   with the `rc.0` for the next release (e.g. `v0.15.0-rc.0`).\n1. **verify**: Verify all artifacts have been published successfully, perform\n   sanity testing.\n1. **promote**: Run the `Promote` action to promote release to desired\n   channel(s).\n1. **release notes**: Publish well authored and complete release notes on\n   GitHub.\n1. **announce**: Announce the release on Crossplane social media accounts.\n\n## Detailed Process\n\nThis section will walk through the release process in more fine grained and\nprescriptive detail.\n\n### Feature Freeze\n\nFeature freeze should be performed on all repos.  In order to start the feature\nfreeze period, the following conditions should be met:\n\n\n* All issues in the\n  [milestone](https://github.com/crossplane/crossplane/milestones) should be\n  closed\n* Sanity testing has been performed on main development branch\n\n### Pin Dependencies\n\nIt is a best practice to release Crossplane projects with \"pinned\" dependencies\nto specific stable versions. For example, after crossplane-runtime has been\nreleased, we want to update the main Crossplane repo to use that specific\nreleased version.\n\nTo update a dependency to a specific version, simply edit the `go.mod` file to\npoint to the desired version, then run `go mod tidy`.\n\n### Create Release Branch\n\nCreating the release branch can be done within the [GitHub\nUI](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-and-deleting-branches-within-your-repository).\nBasically, you just use the branch selector drop down and type in the name of\nthe new release branch, e.g. `release-0.5`. Release branch names always follow\nthe convention of `release-[minor-semver]`.\n\nIf this is the first ever release branch being created in a repo (uncommon), you\nshould also set up branch protection rules for the `release-*` pattern. You can\nfind existing examples in the [Crossplane repo\nsettings](https://github.com/crossplane/crossplane/settings/branches).\n\nAt this point, the `HEAD` commit in the release branch will be our release\ncandidate. The build pipeline will automatically be started due to the create\nbranch event, so we can start to perform testing on this build. Note that it\nshould be the exact same as what is currently in main development branch since\nthey are using the same commit and have the same tag. Also note that this is not\nthe official release build since we have not made the official release tag yet\n(e.g. `v0.5.0`).\n\n### Release Branch Prep\n\nSome repos may not require any release branch prep. This is desirable as it\nreduces the burden of running a new release. If this is the case for the repo\nbeing released, you may skip this step.\n\nIn the core Crossplane repository, we need to update the release branch docs and\nexamples to point to the new versions that we will be releasing soon.\n\n* Documentation, such as pinning\n  [snippet](https://github.com/crossplane/crossplane/blob/release-0.14/docs/snippets)\n  links to the current release branch.\n  * searching for `:v` will help a lot here\n\n#### Bug Fixes in Release Branch\n\nDuring our testing of the release candidate, we may find issues or bugs that we\ntriage and decide we want to fix before the release goes out. In order to fix a\nbug in the release branch, the following process is recommended:\n\n1. Make the bug fix into main development branch first through the normal PR\n   process\n    1. If the applicable code has already been removed from the main development\n       branch then simply fix the bug directly in the release branch by opening\n       a PR directly against the release branch\n1. Backport the fix by performing a cherry-pick of the fix's commit hash\n   (**not** the merge commit) from main development branch into the release\n   branch. For example, to backport a fix from the main development branch to\n   `v0.5.0`, something like the following should be used:\n\n    ```console\n    git fetch --all\n    git checkout -b release-0.5 upstream/release-0.5\n    git cherry-pick -x \u003cfix commit hash\u003e\n    ```\n\n1. Open a PR with the cherry-pick commit targeting the release-branch\n\nAfter all bugs have been fixed and backported to the release branch, we can move\non to tagging the final release commit.\n\n### Tag Release\n\nNow it's time to run the `Tag` action on the release branch.\n\nRun the tag action by going to the repo's \"Actions\" tab in the Github UI. You\nwill be prompted for the desired branch and the version you are tagging. The\nlatest commit on the selected branch will be the commit that is tagged.\n\n### Draft Release Notes\n\nWe're getting close to starting the official release, so you should take this\nopportunity to draft up the release notes. You can create a [new release draft\nhere](https://github.com/crossplane/crossplane/releases/new).  Make sure you\nselect \"This is a pre-release\" and hit \"Save draft\" when you are ready to share\nand collect feedback.  Do **not** hit \"Publish release\" yet.\n\nYou can see and follow the template and structure from [previous\nreleases](https://github.com/crossplane/crossplane/releases).\n\n### Build and Publish\n\nRun the `CI` action on the release branch. This will build and publish the\nofficial release with the correct version tag and all of its release artifacts\nwill be published.\n\nIf there are any `Configuration` packages that are built in the repo, you must\nalso run the `Configurations` action on the release branch. This will build,\ntag, and publish the `Configuration` packages to the configured OCI image\nregistry.\n\nAfter the pipeline runs successfully, you should verify that all artifacts have\nbeen published to:\n\nFor all repos:\n* [Docker Hub](https://hub.docker.com/repository/docker/crossplane)\n\nFor all repos with Helm charts:\n* [S3 releases bucket](https://releases.crossplane.io/)\n* [Helm chart repository](https://charts.crossplane.io/)\n\nFor crossplane/crossplane:\n* [Docs website](https://docs.crossplane.io)\n* [Configuration Packages](https://marketplace.upbound.io)\n\n### Tag Next Pre-release\n\nThe next step is to create the pre-release tag for the `HEAD` commit in main\ndevelopment branch. This tag serves as an indication of when the release was\nbranched from the main development branch and is also important for generating\nfuture versions of the main development branch builds since that [versioning\nprocess](https://github.com/upbound/build/blob/master/makelib/common.mk#L182-L196)\nis based on `git describe --tags`.\n\n\u003e NOTE: the `build` submodule uses the latest tag by timestamp on the branch\n\u003e which the commit it is building resides on. If there were no prep commits made\n\u003e on the release branch, then its `HEAD` is even with the main development\n\u003e branch (i.e. the stable tag and the next pre-release tag will be on the same\n\u003e commit). This means that we must tag the pre-release version _after_ the\n\u003e stable version to ensure subsequent builds use the next pre-release tag as\n\u003e their base. If there are additional commits on the release branch before the\n\u003e stable tag is created, then the pre-release tag could be created first.\n\nTo accomplish this, run the `Tag` action for the repo on the main development\nbranch branch. You will be prompted to enter the `version` for the tag. Since\nthis tag will essentially be the start of pre-releases working towards the\n**next** version, the `version` should be the **next** release number, plus a\ntrailing tag to indicate it is a pre-release.  The current convention is to use\n`*-rc.0`. For example, when we are releasing the `v0.9.0` release and we are\nready for the main development branch to start working towards the **next**\nrelease of `v0.10.0`, we would make the tag `v0.10.0-rc.0`\n\nAfter the tag action has succeeded, verify in the [GitHub\nUI](https://github.com/crossplane/crossplane/tags) that the tag was successfully\napplied to the correct commit.\n\nThe main development branch can now be opened for new features since we have a\nsafe release branch to continue bug fixes and improvements for the release\nitself. Essentially, the main development branch is free to now diverge from the\nrelease branch.\n\n### Promote\n\nIf everything looks good with the official versioned release that we just\npublished, we can go ahead and run the `Promote` action on the release branch.\nThis is a very quick pipeline that doesn't rebuild anything, it simply makes\nmetadata changes to the published release to also include the release in the\nchannel of your choice.\n\nRun the `Promote` action on the release branch and input the version you would\nlike to promote (e.g. `v0.5.0`) and the channel you'd like to promote it to.\n\nAfter the `Promote` actions have succeeded, verify on DockerHub and the Helm\nchart repository that the release has been promoted to the right channels.\n\n### Publish Release Notes\n\nNow that the release has been published and verified, you can publish the\n[release notes](https://github.com/crossplane/crossplane/releases) that you\ndrafted earlier. After incorporating all feedback, you can now click on the\n\"Publish release\" button.\n\nThis will send an email notification with the release notes to all watchers of\nthe repo.\n\n### Announce Release\n\nWe have completed the entire release, so it's now time to announce it to the\nworld.  Using the Crossplane social media accounts, post about the new release\nand blog.  You'll see examples from the previous releases, such as this tweet\nfor [v1.18.0](https://x.com/crossplane_io/status/1853803554370097463).\n\nShare a link to the social post on the Slack #announcements channel, then copy a link\nto that and post it in the #general channel.\n\n### Patch Releases\n\nWe also have the ability to run patch releases to update previous releases that\nhave already been published.  These patch releases are always run from the last\nrelease branch, we do **not** create a new release branch for a patch release.\n\nThe basic flow is **very** similar to a normal release, but with a few less\nsteps.  Please refer to details for each step in the sections above.\n\n* Fix any bugs in the main development branch first and then `cherry-pick -x` to\n  the release branch\n  * If main development branch has already removed the relevant code then make\n    your fix directly in the release branch\n* After all testing on the release branch look good and any docs/tests have been\n  updated with the new version number, run the `Tag` action on the release\n  branch with the new patch version (e.g. `v0.5.1`)\n* Run the normal `CI` action on the release branch to build and publish the\n  release\n* Publish release notes\n* Run `Promote` action to promote the patch release to the appropriate channels\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcrossplane%2Frelease","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcrossplane%2Frelease","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcrossplane%2Frelease/lists"}