Hi Adnan, That's a good point, but IMHO this means that test.pypi.org is not suitable as a staging area for ASF releases.
I believe it is critical to validate and vote on exact bits. If the bits change after the vote, in principle there's no guarantee that the vote is still relevant. Is it possible to install the Python CLI locally from the archive hosted on the usual SVN-backed "dev" server (instead of test.pypi.org)? Thanks, Dmitri. On Fri, Apr 17, 2026 at 6:22 PM Adnan Hemani via dev <[email protected]> wrote: > Hi Dmitri, > > I understand your concern about using the version without the RC mark on > test.pypi.org, but we face the issue: what if this RC fails and a new one > needs to be started? I don't think we can "re-release" the same version > number on PyPI/TestPyPI - even if you delete the artifact manually. > > From PyPI's website when I try to delete an artifact: > > > Warning This action cannot be undone! > > You will not be able to re-upload a new distribution of the same type > with the same version number. > > Deletion will break any downstream projects relying on a pinned version > of this package. It is intended as a last resort to address legal issues or > remove harmful releases. > > Consider yanking this release, making a new release or a post release > instead. > > I think Kevin's suggestion to put the "non-RC" version in SVN - and then > uploading that (after RC passes) to PyPI is a good workaround. WDYT? > > Best, > Adnan Hemani > > On Fri, Apr 17, 2026 at 12:18 PM Dmitri Bourlatchkov <[email protected]> > wrote: > > > Hi Kevin, > > > > Thanks for the suggestion for handling RCs with Python artifacts. > > > > The two artifact approach sounds reasonable to me. I assume the file in > SVN > > will also have a co-located (detached) signature file. > > > > Speaking about signatures, and votes, I believe the vote should be on > exact > > binary artifacts; otherwise, signing does not make sense. Therefore, the > RC > > archive uploaded to PyPi cannot be used for validation because it will > not > > exactly match the final artifact (checksums will differ, and signature > > validation will fail). > > > > My personal preference would be to just use a version without the RC mark > > on test.pypi.org (which would match the artifact in SVN). I think the > > "test" area of PyPi provides users with enough notice that the artifacts > > there are not final (yet). > > > > Cheers, > > Dmitri. > > > > On Fri, Apr 17, 2026 at 2:58 PM Kevin Liu <[email protected]> wrote: > > > > > +1 (non-binding) > > > > > > I checked both the source dist and wheel from testpypi: > > > - LICENSE/NOTICE exists > > > - No unexpected binary files > > > - All source files have ASF headers > > > > > > Also ran the CLI locally > > > ``` > > > uvx --index https://test.pypi.org/simple/ --index-strategy > > > unsafe-best-match --from apache-polaris==1.4.0rc0 polaris > > > ``` > > > > > > Would be great to include the python source dist and wheel in the dev > > > release (https://dist.apache.org/repos/dist/dev/polaris/) in the > future. > > > > > > Dmitri, thats a valid point. When the release candidate pass, I would > > > expect the artifact uploaded to PyPi have the version `1.4.0` (without > > the > > > rc suffix). I think it is fine that it's different during the RC > process. > > > It's a convenience to users and can always be rebuilt from the source. > > > > > > In PyIceberg, we build the wheels twice. Once with the RC tag and > upload > > it > > > to PyPI as a pre-release; another without the RC tag and upload to dev > > SVN. > > > During voting, we can check both the uploaded wheels and SVN wheels. > When > > > the RC passes, we use the wheels in SVN to upload the final version to > > > PyPI. > > > > > > Best, > > > Kevin Liu > > > > > > On Thu, Apr 16, 2026 at 4:13 PM Dmitri Bourlatchkov <[email protected]> > > > wrote: > > > > > > > Also, should we sign the Python package > > (apache_polaris-1.4.0rc0.tar.gz) > > > as > > > > we sign the server's binary archives? > > > > > > > > Cheers, > > > > Dmitri. > > > > > > > > On Thu, Apr 16, 2026 at 7:05 PM Dmitri Bourlatchkov < > [email protected]> > > > > wrote: > > > > > > > > > Hi All, > > > > > > > > > > Voting -1 (binding) for now. > > > > > > > > > > Checked (OK): > > > > > * LICENSE > > > > > * NOTICE > > > > > * Package .py file headers (manually sampled) > > > > > * Venv install + CLI smoke test > > > > > > > > > > My contern: > > > > > > > > > > I'm not very familiar with Python packages and test.pypi.org, but > in > > > > > PKG-INFO (inside apache_polaris-1.4.0rc0.tar.gz) I see "Version: > > > > 1.4.0rc0". > > > > > > > > > > I wonder whether this version will change when the artifact is > > promoted > > > > to > > > > > "dist"... Is it a concern? > > > > > > > > > > Also: > > > > > > > > > > $ venv/bin/pip show apache-polaris > > > > > Name: apache-polaris > > > > > Version: 1.4.0rc0 > > > > > > > > > > I'd expect "rc0" to be a transient property of the package while it > > is > > > > > being reviewed and voted on, and that the package should report > > version > > > > > 1.4.0 even while it is staged at test.pypi.org. > > > > > > > > > > If we intend to repackage the CLI for publication in the main PyPi > > > index > > > > > without the "rc0" mark, that will alter PKG-INFO and essentially > > > > invalidate > > > > > this vote, I guess (hence my -1 vote). > > > > > > > > > > The previous (unreleased) version doess not have the "rc" mark in > > > > > https://test.pypi.org/project/apache-polaris/1.2.0/ > > > > > > > > > > WDYT? > > > > > > > > > > If this is not a concern or if I missed something, I'll be happy to > > > > update > > > > > my vote. > > > > > > > > > > Cheers, > > > > > Dmitri. > > > > > > > > > > On Thu, Apr 16, 2026 at 5:03 AM Adnan Hemani via dev < > > > > > [email protected]> wrote: > > > > > > > > > >> Hi all, > > > > >> > > > > >> I propose that we release the following RC as the official Apache > > > > Polaris > > > > >> Python CLI 1.4.0 release. > > > > >> > > > > >> https://test.pypi.org/project/apache-polaris/1.4.0rc0/ > > > > >> > > > > >> Starting with Apache Polaris 1.5.0, the CLI should be released > > > alongside > > > > >> all other release artifacts within the full Polaris Release > > Candidate. > > > > >> Work > > > > >> to make this happen can be found here: > > > > >> https://github.com/apache/polaris/pull/4220 > > > > >> > > > > >> Please vote in the next 72 hours. > > > > >> > > > > >> [ ] +1 Release this as Apache Polaris 1.4.0 > > > > >> [ ] +0 > > > > >> [ ] -1 Do not release this because... > > > > >> > > > > >> Only PMC members have binding votes, but other community members > are > > > > >> encouraged to cast non-binding votes. > > > > >> This vote will pass if there are 3 binding +1 votes and more > binding > > > +1 > > > > >> votes than -1 votes. > > > > >> > > > > >> Best, > > > > >> Adnan Hemani > > > > >> > > > > > > > > > > > > > > > > > > -- > > Dmitri Bourlatchkov > > Senior Staff Software Engineer, Dremio > > Dremio.com > > < > > > https://www.dremio.com/?utm_medium=email&utm_source=signature&utm_term=na&utm_content=email-signature&utm_campaign=email-signature > > > > > / > > Follow Us on LinkedIn <https://www.linkedin.com/company/dremio> / Get > > Started <https://www.dremio.com/get-started/> > > > > > > The Agentic Lakehouse > > The only lakehouse built for agents, managed by agents > > >
