I merged the PR: LGTM, thanks! Regards JB
On Thu, May 21, 2026 at 7:04 PM Yufei Gu <[email protected]> wrote: > Agreed that we cannot change the release artifact. That will require > cutting a new release, like version 1.5.1. It's not worth doing, IMHO. > > Here is a PR for site change: https://github.com/apache/polaris/pull/4513. > Please take a look. > > > > Yufei > > > On Thu, May 21, 2026 at 3:14 AM Robert Stupp <[email protected]> wrote: > > > Just to clarify: I did not block corrections. > > > > I’m trying to separate two things: the voted 1.5.0 release artifact is > > immutable, while the website release notes and the changelog on the main > > branch can still be corrected for accuracy. > > > > I also think we should catch changelog categorization issues earlier > during > > normal PR review, since the changelog ends up in the release artifact. > > > > > > On Thu, May 21, 2026 at 9:40 AM Jean-Baptiste Onofré <[email protected]> > > wrote: > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
