chore: Explain how to promote a beta release #4562
Conversation
Explain how to promote a beta release in Contributing.md
CONTRIBUTING.md
Outdated
| 1. Checkout a new branch from the GH tag of the beta release: `git checkout -b publish/x.x.x x.x.x-beta.1`. You can't use `release/x.x.x` or `x.x.x` as the branch name as craft will fail, as it creates a `release/x.x.x` branch for updating the changelog and it will create a tag `x.x.x` for the release. | ||
| 2. Duplicate the Changelog.md entry of the beta release and change header of the version number to unreleased. | ||
| 3. Commit and push the changes. | ||
| 4. Trigger the release workflow with use workflow from the `publish/x.x.x` branch. |
There was a problem hiding this comment.
m: During the release workflow, we can choose the same branch for Craft to merge it back, so Craft does not fail.
Also, we need to manually update the changelog in the main branch.
There was a problem hiding this comment.
But that sucks pretty much. Ideally, we would merge the branch back to main. Does it then fail if we do that?
There was a problem hiding this comment.
It fails because more likely than not, the main will be "ahead" of the beta tag.
This means "manually update the changelog in the main branch" is not optional, this always need to happen.
There was a problem hiding this comment.
OK, but then I would say let crash merge back into the publish branch and then merge the publish branch manually back to main?
There was a problem hiding this comment.
Yes, we can do that after merging main into the publish branch. Good idea
There was a problem hiding this comment.
I'm also for setting the target as publish/x.x.x for the x.x.x release of x.x.x-beta.x.
And then merging manually, if merged directly to mainl, it will fail in better case, in worse case it will break changelog or code.
Not ideal but safe.
Note: The JS team solved this by using develop branch as default and main for releases. Maybe we could adopt similar workflow in the future.
There was a problem hiding this comment.
I updated the description. @brustolin and @krystofwoldrich please have another look.
|
@codecov-ai-reviewer review |
| 4. Trigger the release workflow with use workflow from the `publish/x.x.x` branch and set the target branch to merge into to `publish/x.x.x`, cause per default craft will merge into the main branch and this could lead to merge conflicts in the changelog. | ||
| 5. Manually open a PR from the `publish/x.x.x` branch into the main branch and merge it. | ||
|
|
||
| After the successful release, craft merges the `publish/x.x.x` branch into the main branch and deletes the release branch. |
There was a problem hiding this comment.
| 4. Trigger the release workflow with use workflow from the `publish/x.x.x` branch and set the target branch to merge into to `publish/x.x.x`, cause per default craft will merge into the main branch and this could lead to merge conflicts in the changelog. | |
| 5. Manually open a PR from the `publish/x.x.x` branch into the main branch and merge it. | |
| After the successful release, craft merges the `publish/x.x.x` branch into the main branch and deletes the release branch. | |
| 4. Trigger the release workflow with use workflow from the `publish/x.x.x` branch and set the target branch to merge into to `publish/x.x.x`, cause per default craft will merge into the main branch and this could lead to merge conflicts in the changelog. | |
| a. After the successful release, craft merges the changes back into `publish/x.x.x` branch and deletes the release branch. | |
| 5. Manually open a PR from the `publish/x.x.x` branch into the main branch and merge it. |
Or something like this.
Explain how to promote a beta release in Contributing.md.
#skip-changelog