-
-
Notifications
You must be signed in to change notification settings - Fork 281
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
Comments
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 ❤️ |
Highlight
semantic-release
doesn't know that and treats all commits and related PRs as release relatedMore 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 example2.5.0-next-spec.4
. Then when we do a release, tag2.5.0
is added tomaster
.So what happened with this release was that for
2.6.0
, the release candidate onnext-spec
was2.5.0-next-spec.5
instead of2.6.0-next-spec.1
.And the reason was that there is no technical information
semantic-release
have no idea that the las tag isv2.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 #674Possible 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#706The text was updated successfully, but these errors were encountered: