I'm with Björn and Brian on keeping the CHANGELOG.md manually curated. You need to understand all relevant changes since the last release anyway as the release shepherd, and it's much easier and less overall overhead to weigh everything centrally in the end than trying to get everyone to formulate changelog entries for every PR that in the end result in a cohesive whole.
On Mon, Feb 17, 2020 at 4:13 PM Łukasz Mierzwa <l.mier...@gmail.com> wrote: > Adopting one of many variants of semantic commits and using one of many > tools that generates a changelog from it can save some time there. > Examples: example: https://www.conventionalcommits.org/, > https://keepachangelog.com/ > Going that path is easier if one uses commit message linter, to ensure all > comit messages follow required format - > https://github.com/conventional-changelog/commitlint > > That being said from a purely user oriented perspectice I always find it > useful when changelog includes a section that gives me a human readable > overview of what's included in given release, that is difficult to automate > but can be added on top of automated changelog. > > On Monday, 17 February 2020 15:06:42 UTC, Björn Rabenstein wrote: >> >> Just my 2¢: >> >> I'm firmly in the camp of hand-creating the CHANGELOG. I do so many >> editorial work on it that a pre-populated CHANGELOG might easily >> create more work than it saves. I do have to understand anyway what >> each change is doing as we are supposed to filter out changes that are >> not user-visible/-impacting (which could as well be that a >> user-visible change was introduced with its corresponding CHANGELOG >> entry, but later it was removed again before a release happened). >> >> I'm essentially doing what Brian is doing when I cut a release. I only >> found that problematic after releases were procrastinated for too long >> and the CHANGELOG exploded. With the fixed cadence in >> prometheus/prometheus, that isn't really a problem anymore (but 2.16.0 >> was a biggie nevertheless). >> >> What is a problem is unclear or incomplete commit and/or PR >> descriptions. I guess we can all agree to ask for those in reviews. >> >> I don't feel strongly about how in detail we want to encourage good >> commit and PR descriptions. If we put a hint in there to suggest a >> changelog line if applicable, I'm all for it. If people want a >> specific keyword to autoextract it, sure, as long as I don't have to >> use it and it doesn't make it harder to contribute. >> >> I would not like to directly edit the CHANGELOG.md file in each PR, >> for all the reasons already stated. >> >> -- >> Björn Rabenstein >> [PGP-ID] 0x851C3DA17D748D03 >> [email] bjo...@rabenste.in >> > -- > You received this message because you are subscribed to the Google Groups > "Prometheus Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to prometheus-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/prometheus-developers/da403d28-cfad-41c2-8d0b-91168be070f5%40googlegroups.com > <https://groups.google.com/d/msgid/prometheus-developers/da403d28-cfad-41c2-8d0b-91168be070f5%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6Yoxd7SOi%2BMPP%3Dbxmhm67kUy1QK_qECwBR1FkTtKU0%2BGFRg%40mail.gmail.com.
