Hi Yufei and Robert, I believe there are two distinct aspects to consider here:
1. A release is immutable. Once the vote has passed, we cannot change the release content, including the CHANGELOG.md file that was part of the release. 2. We should update the release notes on the website ( https://polaris.apache.org/downloads/1.5.0/) to ensure our users are clearly informed. I would also like to emphasize the importance of carefully reviewing and updating CHANGELOG.md during the development process. Since it is used to populate the release notes and is included in the release itself, it must be accurate and informative. I propose creating a PR to update the 1.5.0 release notes on the website. This will not modify the release itself but will correctly reflect what should be considered a breaking change. Regards, JB On Wed, May 20, 2026 at 10:41 PM Yufei Gu <[email protected]> wrote: > It's a good point to review CHANGELOG entries thoroughly during the PR > process. That said, I don't think we should avoid fixing inaccuracies after > that. IMO, release time is also an important opportunity to correct > anything misleading or incorrectly categorized, since that's when the > changelog becomes especially visible and important to users. > > So I don't fully understand the reason to block changes at that point. > > Yufei > > > On Wed, May 20, 2026 at 10:38 AM Robert Stupp <[email protected]> wrote: > > > Thanks for raising this. > > > > I think the main takeaway is: we need to take CHANGELOG.md more seriously > > during normal PR review. > > > > The release notes were copied from the CHANGELOG.md that was included in > > the voted release artifact. > > Once we are at that stage, I don’t think the release publication PR is > the > > right place to re-classify entries unless something is obviously broken. > > The better place to catch this is when the original PR adds or changes > the > > changelog entry. > > > > So I’d suggest that for PRs touching user-visible behavior, APIs/SPIs, > > config, deprecations, fixes, etc., reviewers also check the CHANGELOG.md > > entry itself: right section, accurate wording, and not just “some entry > > exists”. > > > > That way we don’t end up discovering during release voting or after > release > > publication that entries which were already authored/reviewed/merged as > > part of normal development maybe belonged somewhere else. > > > > Robert > > > > On Wed, May 20, 2026 at 7:07 PM Yufei Gu <[email protected]> wrote: > > > > > Congrats on the new release! Thanks a lot for driving this release, JB! > > > That's really a fast turn-around! Great job! > > > > > > As I mentioned in > > > https://github.com/apache/polaris/pull/4483#discussion_r3262756089, we > > > will > > > need to fix the release notes a bit. > > > > > > Yufei > > > > > > > > > On Wed, May 20, 2026 at 8:53 AM Dmitri Bourlatchkov <[email protected]> > > > wrote: > > > > > > > Hi JB, > > > > > > > > Thanks for driving this release! > > > > > > > > Cheers, > > > > Dmitri. > > > > > > > > On Wed, May 20, 2026 at 2:24 AM Jean-Baptiste Onofré < > > > [email protected]> > > > > wrote: > > > > > > > > > The Apache Polaris team is pleased to announce Apache Polaris > 1.5.0. > > > > > > > > > > This release includes: > > > > > - Apache Ranger support as an external authorizer > > > > > - Improvements on the CLI > > > > > - Improvements on the Helm Charts > > > > > - Improvements on the events listeners > > > > > > > > > > You can download this release and find details on this release > here: > > > > > https://polaris.apache.org/downloads/1.5.0/. > > > > > > > > > > Artifacts are available on Maven Central. > > > > > > > > > > Apache Polaris is an open-source, fully-featured catalog for Apache > > > > > Iceberg™. It implements Iceberg's REST API, enabling seamless > > > > multi-engine > > > > > interoperability across a wide range of platforms, including Apache > > > > Doris™, > > > > > Apache Flink®, Apache Spark™, Dremio®, StarRocks, and Trino. > > > > > > > > > > > > > > > Enjoy ! > > > > > The Polaris team > > > > > > > > > > > > > > >
