I'm proposing CHANGELOG not as a replacement for Release Notes, but as a method for accumulating important notices as PRs are merged between releases.
CHANGELOG could be used as input into Release Notes (or standalone). Cheers, Dmitri. On Fri, May 16, 2025 at 9:42 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > 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 > > > > > >
