Hi folks Creating this thread to avoid hijacking the 1.1.0 release thread.
The topic of keeping a change log for breaking changes was already discussed on the dev mailing list [1]. But one point related to ownership of CHANGELOG.md consistency was not addressed [2]. And I would like to revive this discussion. During the 1.1.0 release preparation, it became clear that the CHANGELOG.md had not been updated with newly added features and important bugfixes. As part of that release prep, I tried to rebuild that information out of the 350 (and counting) commits that had been added to `main` since the last release, and add them to the CHANGELOG.md [3]. As Robert mentioned [4], this is kind of archeological research. The release manager may not have the context related to each PR, and may miss some features that should be present in the change log. This is far from ideal as the change log is the first thing users will see before downloading a new version. The purpose of this thread is to discuss the idea of requiring CHANGELOG.md updates as part of each _applicable_ PR. I believe that this would greatly simplify cherry-picks of commits over release branches, and it would also move us one step closer to having anybody serve as the release manager, which is used to demonstrate the project maturity. As an example, Apache Beam already follows this model. We can see in their `CHANGES.md` Git history that it is updated with every non-trivial contribution [5]. Wdyt? [1] https://lists.apache.org/thread/qznf8toht1r7ml35lt4p8nwlk9op638v [2] https://lists.apache.org/thread/c9y0f0z7nyoclvtzr12v8ryqq55dqzd5 [3] https://github.com/apache/polaris/pull/2406 [4] https://lists.apache.org/thread/pt560j450f520nh8to6m322jr4mod0mm [5] https://github.com/apache/beam/commits/master/CHANGES.md -- Pierre
