Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problems with release and long living branches #899

Closed
derberg opened this issue Jan 31, 2023 · 1 comment
Closed

Problems with release and long living branches #899

derberg opened this issue Jan 31, 2023 · 1 comment

Comments

@derberg
Copy link
Member

derberg commented Jan 31, 2023

Highlight

  • to update long living branches we do normal merge, so we merge all commits from master, that are not related to the release branch, but during release semantic-release doesn't know that and treats all commits and related PRs as release related
  • long living branches are tagged with release candidates but never final release

More details

For the post release task we need to solve one problem that we had with this release. Now we have a long living next-spec branch that stays there forever. When we release candidates, next-spec is tagged with RC name like for example 2.5.0-next-spec.4. Then when we do a release, tag 2.5.0 is added to master.

So what happened with this release was that for 2.6.0, the release candidate on next-spec was 2.5.0-next-spec.5 instead of 2.6.0-next-spec.1.

[9:27:17 AM] [semantic-release] › ℹ  Found git tag v2.5.0-next-spec.4 associated with version 2.5.0-next-spec.4 on branch next-spec

And the reason was that there is no technical information semantic-release have no idea that the las tag is v2.5.0.

It is not possible to check why in previous releases we did not face this issue as logs on CI are not preserved that long.


Now, problem is also when we merge changes from master to release branches. Then semantic-release treats these commits as part of the release, so then adds wrong comments to issues like #674

Possible solutions

The easiest is to drop the idea of long-living branches like next-spec and do as we did before, branches for a given release only that we remove after release. I see no benefit of long living branches, other than that we just do not have to create new branch for each release, but this can be delegated to GitHub workflow that will do it for us, and we anyway need to open update PRs asyncapi/parser-js#706

This was referenced Jan 31, 2023
@github-actions
Copy link

github-actions bot commented Jun 1, 2023

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

@github-actions github-actions bot added the stale label Jun 1, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Sep 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant