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

Prevent merge conflicts and changelog entries being added to the wrong release #8272

Open
bmw opened this issue Sep 8, 2020 · 5 comments · May be fixed by #9803
Open

Prevent merge conflicts and changelog entries being added to the wrong release #8272

bmw opened this issue Sep 8, 2020 · 5 comments · May be fixed by #9803
Assignees
Labels
area: pkging area: tooling priority: significant Issues with higher than average priority that do not need to be in the current milestone.

Comments

@bmw
Copy link
Member

bmw commented Sep 8, 2020

Merge conflicts in our changelog are relatively common. There was some discussion about this issue and how to fix it in #6462.

Another common problem is the changelog entry getting added to a past release which happened in #8212 and #8263.

Is there an easy way for us to avoid these problems? I have no experience with how other projects handle this, but I have to imagine someone out there has solved these problems before.

I personally think we should continue to have the PR author and reviewer handle writing a changelog entry. For Certbot in the past, the person doing the release would manually write all entries, but this adds a lot of manual overhead and requires the person doing the release to have a good understanding of all changes made to Certbot since the last release.

EDIT: One idea I had here to solve the problem of entries getting added to the wrong section is to keep all new changelog entries separate from our released changelog and then prepend the new changelog entries to the top automatically during the release. We'd also automatically delete entries stored outside the changelog so they aren't added again in our next release.

@bmw bmw added area: pkging area: tooling priority: significant Issues with higher than average priority that do not need to be in the current milestone. labels Sep 8, 2020
@ohemorange
Copy link
Contributor

Personally, I try to wait until getting approved before adding the CL entry, then get another small approval, to make sure it's the last thing added.

@bmw
Copy link
Member Author

bmw commented Oct 27, 2022

Another idea I had here recently would be to write a test that strips off the beginning of the current changelog and then compares it to the changelog from the last release which could be obtained through git/GitHub.

This would prevent us from changing previous changelog entries without ignoring this test, but since changing previous changelog entries is almost always a mistake, maybe this is OK.

@ohemorange
Copy link
Contributor

Oh, I like that!

@bmw
Copy link
Member Author

bmw commented Mar 30, 2023

An even better idea I had is to start using towncrier which is "Used by Twisted, pytest, pip, BuildBot, and attrs, among others."

@wgreenberg
Copy link
Collaborator

added a PR w/ basic towncrier integration, and it works pretty well! the default changelog format towncrier outputs is different from ours, but IMO not in a bad way. if we wanted, we could customize it to only have the three categories we tend to include in our changelog (added/changed/fixed), but i think the towncrier's defaults (feature, bugfix, doc, removal, misc) might be preferable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: pkging area: tooling priority: significant Issues with higher than average priority that do not need to be in the current milestone.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants