-
Notifications
You must be signed in to change notification settings - Fork 556
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
Fix changelog for alpha1 #18451
Comments
Discussed during planning with @npepinpe and @felix-mueller We will time-box this, and check whether it is easy to fix. If not we plan to write at least a note on the release notes, to mark the changelog as containing some old issues. This issue will likely come back on 8.6.0, as this will be the next minor containing the Tasklist commits again in the changelog. BUT DevEx is currently working on a new way to visually represent our release notes in the docs, which makes our release notes maybe obsolete. |
Taking a look at the zcl and where the magic is done https://github.com/zeebe-io/zeebe-changelog/blob/main/pkg/gitlog/gitlog.go We can see that it is essential similar to: As we now merge always with the merge commit, which contains the PR description and issue reference we actually can easily also use Furthermore, as Tasklist before didn't used merge commits this will help us to exclude this from the history/changelog. @npepinpe what do you think about this approach? This would help us for upcoming 8.6.0 release I think. Now we have the case that we already have issues marked. That we want to undo. Maybe we just delete the label, recreate it and relabel the correct issues again? |
Happy for input from @romansmirnov @houssain-barouni @cmur2 as well here (to the idea above) |
Considering this is only to handle previous changes, it should work fine. Meaning, if Tasklist decides to use merge commits now, it shouldn't break anyway since they will sequence their issues with ours, so there won't be any collisions. The only issue is breaking things if we drop merge commits, but I don't foresee this since we use the merge queues. |
UpdateI deleted the alpha1 label from the repo and recreated it. BeforeAround ~160 issues are referenced: In the changelog we see a lot of old issues AfterWith the change only half of them were valid, and have been updated again. |
I created a new release of zcl https://github.com/zeebe-io/zeebe-changelog/releases/tag/v0.8.0 |
Ok looks like that Operate uses merge commits at the begin:
This means this solution doesn't work well enough for 8.5.0 (it excludes already some but not all necessary old issues) |
I might have found an solution based on the time of when the tag has been created
Git magic. I just need to get this into the zcl tool now. |
UpdateGot it working with zcl and 8.5.0 as well. We had around 880 issues marked with our 8.5.0 label. When the recent version 0.8.0 with using only merge commits, we came down to ~570 issues, but we were still referencing old issues. The problem was as described above that Operate used at the begin merge commits as well I was able to use the start tag date as filter with the Updated changelogBeforeAfter |
I created a PR to add this feature zeebe-io/zeebe-changelog#18 |
Changelogs have been cleaned up. We now have a persistent solution, release for ZCL as well. This should work for the upcoming release (8.6.0) as well. With this I will close this issue. |
See related thread
Problem:
The changelog contains right now old issues that were not part of the release.
Root cause:
We have merged tasklist (and operate) git history into our repo. Tasklist is a younger project and referencing younger issues (lower issues numbers) with having these commits in our history our ZCL (changelog tool) gets confused and produces a wrong changelog.
The text was updated successfully, but these errors were encountered: