This content originally appeared on DEV Community and was authored by Alex Merced
- Free Apache Iceberg Course
- Free Copy of “Apache Iceberg: The Definitive Guide”
- Free Copy of “Apache Polaris: The Definitive Guide”
- Purchase "Architecting an Apache Iceberg Lakehouse" (50% Off with Code MLMerced)
- 2025 Apache Iceberg Architecture Guide
- Iceberg Lakehouse Engineering Video Playlist
- Ultimate Apache Iceberg Resource Guide
The Apache Polaris project continues to evolve quickly. Last week the dev mailing list was full of discussions about documentation, release management, storage plug‑ins, credentials and changelog processes. Here’s a round‑up of the most interesting threads and proposals.
1 Documenting patch releases
Eric Maynard noticed that the project’s documentation site has a page dedicated to v1.0.1 in addition to the existing v1.0 docs. He pointed out that if every patch release gets its own section the documentation menu could become cluttered. Eric asked whether docs should be grouped by major/minor releases, hidden from the menu or otherwise consolidated. Dmitri Bourlatchkov proposed keeping only the three most recent patch versions for each minor release; for example, once v1.1.0 ships the site would keep pages for 1.0.1 and 1.1.0, but older patches could be retired. Pierre Laporte agreed with the idea but cautioned against removing documentation too quickly when monthly releases are happening. Jean‑Baptiste Onofré (JB) noted that docs should only be published for major releases (e.g. 1.0.x or 1.1.x) and promised to open a pull‑request to tidy up the site.
Thread: https://lists.apache.org/thread/51b49v4wndq1zqzttom19mdb31j5p6fn
2 Preparing the v1.1.0‑incubating release
JB kicked off a thread about cutting v1.1.0‑incubating. At that time 18 issues were assigned to the 1.1.0 milestone on GitHub. JB proposed bumping enhancements and proposals to the v1.2.0‑incubating milestone (planned for September) and starting the 1.1.0 release process by the end of the week. Dmitri reviewed the open bugs and offered to merge fixes for issues 2367 and 1901 before the cut while deferring the more complex issue 552 to 1.2.0. Further down the thread Dmitri mentioned that pull‑request 2197 (authentication changes) should be deferred because it alters security behaviour, whereas pull‑request 2401 (behavioural changes) needs to be merged before the release.
Thread: https://lists.apache.org/thread/hq6qg83dh9q0jqn15z98lz0pq2c00f
3 Pluggable extraction of storage configuration
Currently Polaris has a hard‑wired mechanism for extracting PolarisStorageConfigurationInfo from entities. Dmitri Bourlatchkov suggested adding a new plug‑in point in core to extract storage configuration and pass it on to PolarisStorageIntegrationProvider. The aim is to make storage integrations more flexible and better aligned with downstream projects. Dmitri is working on a pull‑request and invited feedback on whether the approach makes sense.
Thread: https://lists.apache.org/thread/w45skttdfov42tw624pz8bcgy95yj5do9
4 Making the roleArn parameter optional
Robert Stupp proposed making the roleArn parameter of the REST catalog optional. Many non‑AWS S3‑compatible storage back‑ends (e.g. MinIO, Ceph) can operate without a role ARN, and requiring one forces users to generate dummy values. Dmitri responded that removing the requirement is backwards compatible and improves UX for non‑AWS S3. Dennis Huo added a detailed comment about three new use‑cases uncovered during testing: (1) using the default credentials provider without sub‑scoping to access AWS S3; (2) using it to access non‑AWS S3; and (3) using it with sub‑scoping to access non‑AWS S3. He noted that setting polaris.features.SKIP_CREDENTIAL_SUBSCOPING_INDIRECTION=true already supports some of these cases but that the role‑ARN validation needs to be relaxed. Dennis pointed out that MinIO’s AssumeRoleWithWebIdentity flows still require a role ARN and suggested that separate features may be needed for multi‑tenant deployments.
Thread: https://lists.apache.org/thread/zbh8morrdkjg05rlc4zlrttrt65j5jf3xf
5 Enforcing changelog updates in every PR
Pierre Laporte revived an earlier discussion about maintaining CHANGELOG.md. During 1.1.0 release prep he discovered that the changelog had not been updated for many months, forcing the release manager to trawl through more than 350 commits to identify user‑visible changes. Pierre proposed requiring contributors to update the changelog as part of any PR that adds a feature or fixes a bug. He noted that Apache Beam follows a similar practice, making it trivial to assemble release notes. The thread did not receive many responses, but Pierre argued that enforcing changelog entries would simplify cherry‑picks across release branches and demonstrate the project’s maturity.
Thread: https://lists.apache.org/thread/450ozzdws4v580mom1jzs32wfgs48005
6 Events API & Interface community sync
Adnan Hemani invited contributors to a community sync on August 25 to discuss the proposed Events API & Interface. Several earlier discussions had highlighted the need for a unified event interface across different Polaris services. The upcoming meeting aims to align the design and gather feedback before moving forward.
Thread: https://lists.apache.org/thread/qzm82oc174on2yhp4xrm8m5bt26zrspr (Events sync invitation)
7 Feature flag for credential refresh
Dmitri Bourlatchkov introduced a feature flag to include a credential refresh configuration in REST catalog responses. The existing API can refresh access credentials on demand, but the configuration is not exposed to clients. The proposed change allows catalog clients (such as the Iceberg connector) to learn about credential lifetimes and automatically refresh them before expiry.
Thread: https://lists.apache.org/thread/6tnn97lsvlcgj8n4ojca9lx9d59tq83w
8 Improving GitHub labels and pull‑request triage
Robert Stupp opened a short thread about labels for GitHub issues and PRs. He observed that the existing label set had grown organically and was confusing new contributors. The proposal was to create a concise set of labels for bug fixes, enhancements, documentation, refactoring and proposals, and to update the bot that automatically triages PRs. The community largely agreed that a clearer label taxonomy would help maintainers prioritise work.
Thread: https://lists.apache.org/thread/1rk8rwvyxz282lohr4wx8w6bnctscmk7
9 ActiveRolesProvider and security context improvements
Alexander Dutra resumed a discussion about the ActiveRolesProvider that was introduced earlier in the year. The new provider enriches the security context with role information derived from a user’s groups. Alexander proposed decoupling role provisioning from account authentication and integrating the provider into the core authentication module. The thread also touched on pending issues around multi‑tenant deployments and custom role stores.
Thread: https://lists.apache.org/thread/69hkb7kv4ccm51w7am1j9xrvh3psb56k
10 Release of v1.0.1‑incubating
Towards the end of the week JB sent an announcement that Apache Polaris 1.0.1‑incubating has been released. The maintenance release fixes several critical bugs discovered after the 1.0.0 cut and includes updates to the chart generator and storage configuration. Community members congratulated the release manager and verified that the new artifacts pass integration tests.
Thread: https://lists.apache.org/thread/90cnk6gycw2mc9czsw4zmk9lg5bk5pku
Closing thoughts
The week’s conversations highlight the tension between rapid iteration and maintainability. As Polaris moves to a monthly release cadence, the community is grappling with how to manage versioned documentation and changelogs without overburdening release managers. Meanwhile, core design questions—such as plugin points for storage configuration, optional role ARNs and credential refresh semantics—show that the project is working to support a wider range of storage back‑ends and deployment scenarios. If you’re interested in contributing or following along, join the dev list and participate in the next community sync!
This content originally appeared on DEV Community and was authored by Alex Merced
Alex Merced | Sciencx (2025-08-25T14:40:32+00:00) Apache Polaris Dev Mailing List — Weekly Digest (Aug 17–23 2025). Retrieved from https://www.scien.cx/2025/08/25/apache-polaris-dev-mailing-list-weekly-digest-aug-17-23-2025/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.