Hi all, It's great to focus on nightly/snapshot publications to test.pypi.org first! Can we change the scope of the PR [1] to just this and leave release-candidates and SVN out?
Robert [1] https://github.com/apache/polaris/pull/3036 On Thu, Nov 20, 2025 at 3:38 AM Honah J. <[email protected]> wrote: > > Hi everyone, > > Thanks for all the great points and suggestions! These are key elements for > a robust release process of Python CLI. Given the number of missing pieces > and to move this forward enough parallelization, I think we could have the > following three tracks: > 1. Have a formalized way to build release artifacts (wheels) that will > later be released to PyPI for users to install. > 2. Have ASF-compliant LICENSE/NOTICE/DISCLAIMER > 3. Have a formalized way to build and upload release candidate that include > proper signature and checksum of release artifacts (release automation > pipeline) > > Track 1's PR is out for review:[1] . Once merged, we’ll have CI coverage to > ensure that future Python CLI changes don’t break the release artifacts, > preventing delays in our release cycle. This will also allow us to enable > nightly builds to test.pypi.org as JB mentioned. My proposal document > includes an example from PyIceberg as well: [2]. > > I've also created an issue for 3: [3] > > Thanks again also the generous offers to help. Looking forward to getting > the full publication workflow in place as a community! > > [1]: https://github.com/apache/polaris/pull/3036 > [2]: > https://docs.google.com/document/d/1gbKYnFftpq884GhJ59waHdfoQG6MrevVAVCspf3hbrk/edit?tab=t.0#heading=h.4vtad7spzmcr > [3]: https://github.com/apache/polaris/issues/3098 > > On Wed, Nov 19, 2025 at 4:55 PM Jean-Baptiste Onofré <[email protected]> > wrote: > > > Hi, > > > > I have a proposal regarding the use of PyPI for our Python CLI publishing. > > > > To facilitate nightly builds and staging of release candidates for > > voting, I propose we utilize test.pypi.org. This platform is > > specifically designed for testing and previewing packages, and several > > Apache projects are already using it for this purpose. > > > > For example, you can see how the Apache OpenDAL project utilizes it > > here: https://test.pypi.org/project/opendal/ > > > > This approach would provide an appropriate environment for nightly and > > pre-release artifacts. > > > > Regards, > > JB > > > > On Wed, Nov 19, 2025 at 12:25 PM Robert Stupp <[email protected]> wrote: > > > > > > Hi all, > > > > > > +1 to what JB said. > > > > > > Want to emphasize that it's not only about the presence and > > > correctness of the LICENSE/NOTICE/DISCLAIMER files, but also quite a > > > few process and technical details. > > > Following the rules [1] is also a hard requirement [2], including the > > > implicit technical requirements including, but not limited to, > > > signatures, checksums and the artifact contents. > > > Especially for releases we, as the project, have to make sure to stage > > > artifacts to start the vote, that every committer can verify all > > > artifacts for the release vote and that exactly the same artifacts are > > > eventually published. > > > Even small technical and legal mistakes in the staged artifacts or of > > > the vote itself have led to "failed" release votes in many ASF > > > projects in the past. > > > > > > I am happy to help with that from the release automation side of things! > > > > > > Robert > > > > > > [1] https://www.apache.org/legal/release-policy.html > > > [2] https://lists.apache.org/thread/djfpls35shngokr4rkp3m9s71qs366w5 > > > [3] https://polaris.apache.org/community/release-guide/ > > > > > > > > > On Wed, Nov 19, 2025 at 8:48 PM Jean-Baptiste Onofré <[email protected]> > > wrote: > > > > > > > > Hi folks, > > > > > > > > I want to reiterate the importance of ensuring legal compliance before > > > > publishing any public artifacts. As packages on PyPI are considered > > > > release artifacts, we must confirm that the Python CLI adheres to all > > > > ASF policies, especially regarding incubation status. > > > > > > > > I have addressed the LICENSE/NOTICE requirement on the GitHub project > > > > board (https://github.com/orgs/apache/projects/540/views/1) by > > > > assigning the relevant issue. We must also confirm that the Incubator > > > > DISCLAIMER is included and that the package name and version clearly > > > > reflect the incubating status. > > > > > > > > Legal correctness is a hard requirement and a necessary blocker before > > > > we proceed with publishing any public artifacts. I will perform a > > > > complete pass and review of these details. > > > > > > > > Thanks, > > > > Jean-Baptiste Onofré > > > > > > > > On Tue, Oct 14, 2025 at 9:17 AM Honah J. <[email protected]> wrote: > > > > > > > > > > Hi everyone, > > > > > > > > > > I’d like to start a discussion about publishing the Apache Polaris > > Python > > > > > CLI to PyPI and providing nightly builds (test PyPi). > > > > > > > > > > The main goal is to make the CLI easier to install (pip install > > > > > <package_name>) and to align its release and distribution process > > with ASF > > > > > guidelines. I’ve drafted a proposal [1] that outlines the key > > requirements > > > > > and the high-level release process if we include the Python CLI in > > the next > > > > > release. The proposal also covers how we might set up nightly builds > > on > > > > > Test PyPI for early testing. > > > > > > > > > > While some details can be finalized later, I’d like to first gather > > > > > feedback on the overall direction — specifically, whether the > > community > > > > > agrees with publishing to PyPI and providing nightly builds. > > > > > > > > > > If there’s general agreement, I plan to open two separate [VOTE] > > threads to > > > > > formalize these decisions: > > > > > 1. Whether to the Python CLI to PyPI > > > > > 2. Whether to provide nightly build (publish to test PyPi) > > > > > > > > > > Please let me know what you think! > > > > > > > > > > [1] > > > > > > > https://docs.google.com/document/d/1gbKYnFftpq884GhJ59waHdfoQG6MrevVAVCspf3hbrk/edit?usp=sharing > > > > > > > > > > > > > > > Best regards, > > > > > Jonas > >
