There is some manual overhead, but I think the alternative is worse (breaking changes go untracked). It's a good idea to have an ongoing changelog like this, and I don't see a way to manage it other than manually.
Your point around consistency is an important one. The example in the linked Nessie PR looks pretty good to me, with a short blurb for each item and a link to the PR. I suppose the exact criteria that necessitate an entry to the changelog are also a little unclear, but in general if there's a user-facing change that a single reviewer feels warrants an entry I feel we're better off adding it. I agree with JB that this feels similar to updating documentation when you make a code change. --EM On Thu, May 15, 2025 at 11:09 PM Yufei Gu <flyrain...@gmail.com> wrote: > It does seem to introduce quite a bit of manual overhead. I’m personally > not a big fan of that, but I’m open to trying it out. That said, I believe > the release manager should have the ability to organize the changelog at > release time, since it’s quite difficult to maintain consistency from the > perspective of individual PRs. For example, contributors might add > something, then revise or remove it later. If the changelog entries are > immutable, the history could become messy and confusing. Dmitri mentioned > that changelog could be updated by PRs, which seems a reasonable fixing > resort to me. > > Yufei > > > On Thu, May 15, 2025 at 7:27 PM Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > > > Hi Dimitri > > > > It's a good idea. > > > > I think each committer should be responsible to update the CHANGELOG > > if appropriate, and reviewer should point it out if needed. > > > > It's the same as documentation, license update and header (when code > > is copied from another project), etc. > > > > Regards > > JB > > > > On Thu, May 15, 2025 at 9:10 PM Dmitri Bourlatchkov <di...@apache.org> > > wrote: > > > > > > Hi All, > > > > > > As discussed in the community sync today, Polaris evolves quickly and > > > breaking changes are a reality we have to live with :) > > > > > > However, I'd like to propose improving user and developer experience by > > > keeping a change log with a section for breaking changes. > > > > > > We follow this practice in Nessie [1] with the help of the > > > "jetbrains-changelog" build plugin to automate adding versioned > sections > > [2] > > > > > > * PRs that have strong user-visible effects also update the appropriate > > > section of the change log. > > > * At release time, the "in progress" entries are moved to a version > > > sub-section automatically. > > > * I'd also propose additionally mentioning PRs with "breaking changes" > on > > > the dev ML list before merging. > > > > > > WDYT about introducing this workflow in Polaris? > > > > > > Thanks, > > > Dmitri. > > > > > > [1] https://github.com/projectnessie/nessie/blob/main/CHANGELOG.md > > > [2] https://github.com/projectnessie/nessie/pull/7243 > > >
