Open
Conversation
|
@aniruddha2000: The label(s) DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
ske-prow
bot
added
the
size/M
dergeberl
requested changes
Mar 12, 2026
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
xoxys
requested changes
Mar 31, 2026
Member
xoxys
left a comment
xoxys
left a comment
There was a problem hiding this comment.
In general, we should follow the document structure from https://github.com/stackitcloud/cloud-provider-stackit/blob/main/docs/release-procedure.md e.g.
dergeberl
requested changes
Mar 31, 2026
dergeberl
reviewed
Apr 2, 2026
docs/releases.md
Outdated
| git checkout -b release-vx.y vx.y.0 | ||
| git push -u origin release-vx.y | ||
| ``` | ||
| 3. Use `/cherry-pick release-vx.y` command in the PR with the changes. The ronovate will open the cherry-pick PR automatically. |
Member
There was a problem hiding this comment.
Suggested change
| 3. Use `/cherry-pick release-vx.y` command in the PR with the changes. The ronovate will open the cherry-pick PR automatically. | |
| 3. Use `/cherry-pick release-vx.y` command in the PR with the changes. The prow will open the cherry-pick PR automatically. |
dergeberl
reviewed
Apr 2, 2026
| @@ -1 +1 @@ | |||
| # Release Procedure | |||
Member
There was a problem hiding this comment.
can we keep the same structure of the file as in https://github.com/stackitcloud/cloud-provider-stackit/blob/main/docs/release-procedure.md
Example the Publishing a Release is on the other doc called Automated Release Process (Primary Method. Or Versioning -> General Information
@xoxys added this already as a comment: #136 (review)
dergeberl
reviewed
Apr 9, 2026
|
|
||
| ### Hotfixes | ||
|
|
||
| A Hotfix is required when a critical bug or security vulnerability is discovered in a stable version that is currently in production, but the main branch has already moved forward with breaking changes or features not yet ready for release. |
Member
There was a problem hiding this comment.
Suggested change
| A Hotfix is required when a critical bug or security vulnerability is discovered in a stable version that is currently in production, but the main branch has already moved forward with breaking changes or features not yet ready for release. | |
| A Hotfix is required when a critical bug or security vulnerability is discovered in a stable version that is currently in use, but the main branch has already moved forward with breaking changes or features. |
| commit id: "Critical Bugfix" | ||
| commit id: "Feature B" | ||
| checkout release-v1.0 | ||
| commit id: "cherry-pick Bugfix" tag: "v1.0.1" |
Member
There was a problem hiding this comment.
Suggested change
| commit id: "cherry-pick Bugfix" tag: "v1.0.1" | |
| cherry-pick id: "Bugfix" | |
| commit id: "v1.0.1" tag: "v1.0.1" |
| branch release-v1.0 | ||
| checkout main | ||
| commit id: "Feature A" | ||
| commit id: "Breaking Change" tag: "v2.0.0-beta" |
Member
There was a problem hiding this comment.
Suggested change
| commit id: "Breaking Change" tag: "v2.0.0-beta" | |
| commit id: "Breaking Change" |
We do not use beta releases.
Comment on lines
+16
to
+21
| When releasing machine-controller-manager-provider-stackit, we follow semantic versioning (see https://semver.org/). | ||
|
|
||
| For major version changes, the configuration typically needs to be adapted to accommodate breaking changes before successfully upgrading. For minor and patch updates, no configuration adjustments are required. | ||
|
|
||
| Both major and minor releases are created from the main branch. Patch releases are created from a release branch that is based on a minor version release. | ||
|
|
Member
There was a problem hiding this comment.
Suggested change
| When releasing machine-controller-manager-provider-stackit, we follow semantic versioning (see https://semver.org/). | |
| For major version changes, the configuration typically needs to be adapted to accommodate breaking changes before successfully upgrading. For minor and patch updates, no configuration adjustments are required. | |
| Both major and minor releases are created from the main branch. Patch releases are created from a release branch that is based on a minor version release. | |
| - **Branching Strategy:** All major and minor releases are created from `main` branches. Patch releases are created from `release-v*` branches (see [Patch Release (Hotfix)](#patch-release-hotfix) for more details). | |
| - **Versioning:** Versioning follows official [SemVer 2.0](https://semver.org/) | |
| - **CI/CD System:** All release and image builds are managed by our **Prow CI** infrastructure. |
Lets keep it the same as in cloud-provider-stackit as the information are the same.
|
|
||
| > In the example above, the "Critical Bugfix" cannot be released via the main branch because main contains a "Breaking Change" that isn't ready for general availability. By using a release branch (release-v1.0), we can ship the fix as a patch (v1.0.1) immediately. | ||
|
|
||
| 1. Create a Pull Request (PR) targeting the main branch. Once reviewed and merged, identify the PR number. |
Member
There was a problem hiding this comment.
Suggested change
| 1. Create a Pull Request (PR) targeting the main branch. Once reviewed and merged, identify the PR number. | |
| 1. Create a Pull Request with the bug fix targeting the main branch. | |
| 2. Review and merge the `main` branch Pull Request. |
| git checkout -b release-vx.y vx.y.0 | ||
| git push -u origin release-vx.y | ||
| ``` | ||
| 3. Use `/cherry-pick release-vx.y` command in the PR with the changes. The prow will open the cherry-pick PR automatically. |
Member
There was a problem hiding this comment.
Suggested change
| 3. Use `/cherry-pick release-vx.y` command in the PR with the changes. The prow will open the cherry-pick PR automatically. | |
| 4. Use `/cherry-pick release-vx.y` command in the `main` branch Pull Request. The prow will open the cherry-pick Pull Request against `release-vx.y` branch automatically. |
| git push -u origin release-vx.y | ||
| ``` | ||
| 3. Use `/cherry-pick release-vx.y` command in the PR with the changes. The prow will open the cherry-pick PR automatically. | ||
| 4. Once the cherry-pick PR has been reviewed, approved, and merged, you can promote the changes by creating a new patch release of machine-controller-manager-provider-stackit. |
Member
There was a problem hiding this comment.
Suggested change
| 4. Once the cherry-pick PR has been reviewed, approved, and merged, you can promote the changes by creating a new patch release of machine-controller-manager-provider-stackit. | |
| 5. Once the cherry-pick PR has been reviewed, approved, and merged, you can promote the changes by creating a new patch release of machine-controller-manager-provider-stackit. |
| ``` | ||
| 3. Use `/cherry-pick release-vx.y` command in the PR with the changes. The prow will open the cherry-pick PR automatically. | ||
| 4. Once the cherry-pick PR has been reviewed, approved, and merged, you can promote the changes by creating a new patch release of machine-controller-manager-provider-stackit. | ||
| For this, publish the draft release on the `release-vx.y` branch for the next patch version (`vx.y.z`) (see [Publishing a Release](#-publishing-a-release)). |
Member
There was a problem hiding this comment.
Suggested change
| For this, publish the draft release on the `release-vx.y` branch for the next patch version (`vx.y.z`) (see [Publishing a Release](#-publishing-a-release)). | |
| For this, publish the draft release on the `release-vx.y` branch for the next patch version (`vx.y.z`) (see [Automated Release Process (Primary Method)](#automated-release-process-primary-method)). |
Comment on lines
+58
to
+68
| When changes are merged into `main` or a `release-v*` branch, the `release-tool` creates a draft release to preview the upcoming updates. | ||
| The tool automatically determines the appropriate version tag based on the target branch and the labels of the merged Pull Requests: | ||
|
|
||
| 1. **Draft Creation:** On every successful merge (post-submit) to the `main` branch, a Prow job automatically runs the `release-tool`. This tool creates a new draft release on GitHub or updates the existing one with a changelog generated from recent commits. | ||
| 2. **Publishing the Release:** When the draft is ready, navigate to the repository's "Releases" page on GitHub. Locate the draft, review the changelog, replace the placeholder with your GitHub handle and publish it by clicking the "Publish release" button. | ||
| To publish a release, follow these steps: | ||
|
|
||
| Publishing the release automatically creates the corresponding Git tag (e.g., `v1.3.1`), which triggers a separate Prow job to build the final container images and attach them to the GitHub release. | ||
| 1. Open the repository's releases page. | ||
| 2. Navigate to the corresponding draft release (minor/major for `main`, patch for `release-v*`). | ||
| 3. Review to-be-released changes by checking the release notes. | ||
| 4. Edit the release by pressing the pen icon. | ||
| 5. Change `REPLACE_ME` with your github username. | ||
| 6. Press the "Publish release" button. |
Member
There was a problem hiding this comment.
Suggested change
| When changes are merged into `main` or a `release-v*` branch, the `release-tool` creates a draft release to preview the upcoming updates. | |
| The tool automatically determines the appropriate version tag based on the target branch and the labels of the merged Pull Requests: | |
| 1. **Draft Creation:** On every successful merge (post-submit) to the `main` branch, a Prow job automatically runs the `release-tool`. This tool creates a new draft release on GitHub or updates the existing one with a changelog generated from recent commits. | |
| 2. **Publishing the Release:** When the draft is ready, navigate to the repository's "Releases" page on GitHub. Locate the draft, review the changelog, replace the placeholder with your GitHub handle and publish it by clicking the "Publish release" button. | |
| To publish a release, follow these steps: | |
| Publishing the release automatically creates the corresponding Git tag (e.g., `v1.3.1`), which triggers a separate Prow job to build the final container images and attach them to the GitHub release. | |
| 1. Open the repository's releases page. | |
| 2. Navigate to the corresponding draft release (minor/major for `main`, patch for `release-v*`). | |
| 3. Review to-be-released changes by checking the release notes. | |
| 4. Edit the release by pressing the pen icon. | |
| 5. Change `REPLACE_ME` with your github username. | |
| 6. Press the "Publish release" button. | |
| The primary release method is automated using a tool called `release-tool`. This process is designed to be straightforward and require minimal manual intervention. | |
| 1. **Draft Creation:** On every successful merge (post-submit) to the `main` branch and `release-v*` branchs, a Prow job automatically runs the `release-tool`. This tool creates a new draft release on GitHub or updates the existing one with a changelog generated from recent commits. | |
| 2. **Publishing the Release:** When the draft is ready, navigate to the repository's "Releases" page on GitHub. Locate the draft, review the changelog, replace the placeholder with your GitHub handle and publish it by clicking the "Publish release" button. | |
| Publishing the release automatically creates the corresponding Git tag (e.g., `v1.3.1`), which triggers a separate Prow job to build the final container images and attach them to the GitHub release. |
The information in the same so lets keep it like in cloud-provider-stackit
| checkout main | ||
| commit id: "Feature A" | ||
| commit id: "Breaking Change" tag: "v2.0.0-beta" | ||
| commit id: "Critical Bugfix" |
Member
There was a problem hiding this comment.
Suggested change
| commit id: "Critical Bugfix" | |
| commit id: "Bugfix" |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
How to categorize this PR?
/kind enhancement
/kind documentation
What this PR does / why we need it:
This PR adds documentation for the release process for the machine-controller-manager-provider-stackit. Explaining, major, minor and patch releases and using our release tool.
Special notes for your reviewer:
Breaking changes: