The release manager can organize the changelog but he can’t populate it. Only the authors of the change can (with the reviewer).
Generally speaking, I think we can be helped by a PR label that can pre-populate the changelog. But changelog or label has to be set by the original author. Honestly, not sure a changelog (compared to release notes) would be super helpful but we can give it a try. Regards JB Le ven. 16 mai 2025 à 08:09, Yufei Gu <flyrain...@gmail.com> a écrit : > 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 > > >
