DIM
DIM copied to clipboard
Avoid CHANGELOG.md conflicts
https://about.gitlab.com/blog/2018/07/03/solving-gitlabs-changelog-conflict-crisis/
https://github.com/PrefectHQ/prefect/pull/2529
Using these strategies we could have CHANGELOG.md, CHANGELOG_NEXT.md, and changes/####.md. (where #### = pr#)
CHANGELOG.md is for app and is updated whenever a release is published.
CHANGELOG_NEXT.md is for beta, but only has the currently added notes. it requires concat(CHANGELOG.md)
.
changes/####.md are for unmerged changes which get automatically added to the bottom of CHANGELOG_NEXT.md as merging occurs.
I suppose, though it seems a lot harder than just making sure to update the changelog at some point.
After thinking about this the changes/####.md
could be named anything since only 1 file will exist there at a time in master and only during the deploy-beta flow...
#8250
i thought i thought of a better idea but turns out it sucked. idk how i feel about this it's very unintitive at first glance. are you saying i have to make a pr, see what number it comes out, then make a [that number].md? where does the yaml come into it?
no yaml needed, and the changes/filename.md does not actually matter bc only one will ever get into master...
just have the GHA, check the changes directory and cat any file(s) there onto CHANGELOG_NEXT.md. The only problem I can foresee is multiple PRs getting merged simultaneously cancelling a previous run...