Can we also highlight the key SPI and internal-API changes that service providers with custom plugins should be aware/reminded of at a glance?
In the future perhaps we can use a label or similar on SPI-evolution PRs to better automate aggregating those changes, and also ideally also include SPI changes as part of "proactive" CHANGELOG updates, possibly in a different section from the other API/breaking-changes so that "vanilla" Polaris users only need to look at changes to the public surface area, while customized service-providers would benefit from the SPI evolution section. Also I'm a bit confused about how https://github.com/apache/polaris/pull/2329 "Make S3 roleARN optional" works -- is it falling back to using the server-wide credentials? In any case it needs to be FeatureConfiguration protected. It's also unclear how it works when we still pass the empty roleArn into the AssumeRoleRequest. I'll follow up on the thread about making roleARN optional, but in the meantime for 1.1 purposes we should earmark 2329 as a potential revert until further discussion. On Wed, Aug 20, 2025 at 8:25 AM Dmitri Bourlatchkov <dmitri.bourlatch...@dremio.com.invalid> wrote: > +1 to proactively updating CHANGELOG.md. > > That is how it was originally envisioned [1] :) > > [1] https://lists.apache.org/thread/qznf8toht1r7ml35lt4p8nwlk9op638v > > Cheers, > Dmitri. > > On Wed, Aug 20, 2025 at 6:33 AM Robert Stupp <sn...@snazy.de> wrote: > > > Thanks a lot for tackling this, Pierre! > > > > It's very difficult to figure out all new features, changes and fixes > > "after the fact". > > > > I think we should establish a culture to _proactively_ populate the > > content of CHANGELOG.md _within_ each applicable PR instead of asking > > weeks or months later, or having to figure out all the reasons and > > come up with the "right" categorizations/descriptions/phrases. Doing > > this kind of "archeological research" requires knowledge about all the > > commits/PRs, their background, the implications, etc. This is > > something that we cannot and should not expect from everybody. > > > > Having the CHANGELOG.md updated _in_ a PR makes it _much_ easier to > > "backport" changes from the main branch to for example a `release/1.x` > > branch or the like. > > > > On Wed, Aug 20, 2025 at 11:39 AM Pierre Laporte <pie...@pingtimeout.fr> > > wrote: > > > > > > I just opened https://github.com/apache/polaris/pull/2406 with the > list > > of > > > new features that were added in main since the 1.0.x release branch was > > > cut. Would it be possible to get a review to ensure I did not miss > any? > > > > > > Note that this only contains features, and not fixes. > > > > > > -- > > > > > > Pierre > > > > > > > > > On Wed, Aug 20, 2025 at 12:25 AM Yufei Gu <flyrain...@gmail.com> > wrote: > > > > > > > Hi JB, > > > > > > > > Make sense to move some enhancement and proposals to 1.2. e.g., > > Support for > > > > OpenLineage. Some of 1.1 items have been done, we could close them. I > > haved > > > > moved a few of them to 1.2. > > > > > > > > Meanwhile, can we have a list of new things shipped with 1.1.0? > > > > > > > > Yufei > > > > > > > > > > > > On Tue, Aug 19, 2025 at 2:55 PM Dmitri Bourlatchkov < > di...@apache.org> > > > > wrote: > > > > > > > > > I'd like to merge [2401] before 1.1.0 due to Polaris behaviour > > changes as > > > > > noted in the PR. > > > > > > > > > > Please take a look. > > > > > > > > > > [2401] https://github.com/apache/polaris/pull/2401 > > > > > > > > > > Thanks, > > > > > Dmitri. > > > > > > > > > > On Tue, Aug 19, 2025 at 3:28 PM Jean-Baptiste Onofré < > > j...@nanthrax.net> > > > > > wrote: > > > > > > > > > > > Hi folks, > > > > > > > > > > > > We currently have 18 issues on the 1.1.0 milestone: > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/polaris/issues?q=is%3Aissue%20state%3Aopen%20milestone%3A1.1.0 > > > > > > > > > > > > As we are now starting to have monthly releases, I propose to > bump > > > > > > these GH issues with improvements and proposal labels to the > 1.2.0 > > > > > > milestone (1.2.0-incubating is planned for September). > > > > > > Any objections? > > > > > > > > > > > > For the issues with the "bug" label, I don't see anything major > > but I > > > > > > would like to give a day for the community to take a look. > > > > > > Can you please take a look at the GH issues with the 1.1.0 > > milestone > > > > > > to bump to 1.2.0 (or later) ? > > > > > > Note that we can always include issues for 1.2.0 (September), > 1.3.0 > > > > > > (October), etc. We basically ship what we have :) > > > > > > > > > > > > I will do a new pass tomorrow. I would like to start the 1.1.0 > > release > > > > > > process by the end of this week. > > > > > > > > > > > > Thanks ! > > > > > > > > > > > > Regards > > > > > > JB > > > > > > > > > > > > > > > > > >
