+1 (non-binding) I think it's a great idea, and was about to point out the same automation as Ayush, driven from the JIRA "Release Note" field. Committers just enter text in the optional field when they close the issue, and it's guaranteed to show up when the release gets created.
Chris Nauroth On Mon, Jan 27, 2025 at 8:44 AM Ayush Saxena <ayush...@gmail.com> wrote: > +1, I think Yetus has releasedoc maker [1], which can do it for us, afaik > Hadoop uses it to generate the ReleaseDocs [2] + ChangeLog [3] & it looks > good. I did generate the ChangeLog for 4.x release using this [4], maybe > not awesome but still looked better to me > > -Ayush > > > [1] https://github.com/apache/yetus/tree/main/releasedocmaker > [2] > https://hadoop.apache.org/docs/r3.4.0/hadoop-project-dist/hadoop-common/release/3.4.0/RELEASENOTES.3.4.0.html > [3] > https://hadoop.apache.org/docs/r3.4.0/hadoop-project-dist/hadoop-common/release/3.4.0/CHANGELOG.3.4.0.html > [4] https://hive.apache.org/docs/latest/changelog_283118275/ > > On Mon, 27 Jan 2025 at 16:46, Stamatis Zampetakis <zabe...@gmail.com> > wrote: > >> Hi all, >> >> Currently the release notes are a plain export of the JIRA tickets >> that were resolved in a certain version. Although it is convenient and >> easy to generate by the release manager it usually lacks information >> about breaking/behavior changes, deprecation notices, and appropriate >> documentation entry points for new features and major improvements. >> >> In order to create a better user experience, I was thinking that it >> would be nice to have curated release notes so that end-users can get >> better insights on what's coming with every release. >> >> Concretely, I was thinking of having a new directory in the hive-site >> repo (content/releases) and have a dedicated page for each ongoing >> release (4-1-0-release-notes.md) that we should enrich incrementally >> after resolving an *important* JIRA ticket that requires further >> communication. >> >> By important, I refer mostly to big features/improvements, >> breaking/behavior changes, and deprecation notices. It remains at the >> committers/reviewer/release manager discretion to judge what needs to >> go there and what not. >> >> Consider for example HIVE-27831 [1], that just landed on master. This >> changes the default value of a property thus it would be nice if the >> end-users are aware. >> >> How do people feel about this proposal? >> >> Best, >> Stamatis >> >> [1] https://issues.apache.org/jira/browse/HIVE-27831 >> >
