Re: [Discuss] Streamlining Release Notes Preparation

One suggestion is to prune the list a bit manually. For example, back for the 1.6.0 release, I've sorted the list , which already makes is much easier to read since we do a pretty good job at prefixing the PRs (Spark, Spec, Core,

Re: [Discuss] Streamlining Release Notes Preparation

Hi I agree with Dan and Ryan. On most Apache projects, we use Jira or GH as release notes "links". I think it's good enough with a lot of details. No need to bother the release manager with additional work for not a huge benefit :) Regards JB On Tue, Apr 29, 2025 at 12:47 AM Ryan Blue wrote: >

Re: [Discuss] Streamlining Release Notes Preparation

Thanks for the inputs. Capturing release notes per PR has worked well for projects like Trino and projectNessie. Hence, I suggested the same. I am fine with either approach if the community believes it could be error-prone. - Ajantha On Tue, Apr 29, 2025 at 4:17 AM Ryan Blue wrote: > I don't s

Re: [Discuss] Streamlining Release Notes Preparation

I don't see much value in a release notes file. I think this kind of approach gets ignored and sets up a bad situation where release managers assume that notes are up to date when they aren't. That leads to poorer quality release notes. I think it is reasonable either to use the set of changes that

Re: [Discuss] Streamlining Release Notes Preparation

I'm not a big proponent of adding additional process to PRs/contributions. It's very hard to enforce consistently and then we get the worst of both where there are missing contributions and someone still needs to wade through and diff at the time of release. I find the automated release notes

[Discuss] Streamlining Release Notes Preparation

Hi all, While working on the recent release, I noticed that preparing the release notes is currently a manual process, requiring the release manager to review each commit between releases. This approach is not only time-consuming but can also delay the release announcement. To improve this, I wou