Hi Adnan, Your plan sounds good to me.
I suppose we're going to need both the .tar.gz and the .whl files in SVN with checksums and signatures, right? I'm fine with uploading the CLI to test.pypi.org with RC tags for testing. My point is only that those bundles are not suitable for release validation. Since it is possible to validate the package using the ASF dist server, I'm going to try that option with the next RC. Thanks, Dmitri. On Fri, Apr 17, 2026 at 9:55 PM Adnan Hemani via dev <[email protected]> wrote: > Hi Dmitri, > > Yes, you can do something like this: "pip install > https://example.com/my_package-1.0.0-py3-none-any.whl";. I agree that the > vote should take place on the exact bits that you've verified, but still > see value in the TestPyPI as a way to validate that a successful artifact > with this code can be submitted to PyPI, even if the release name differs. > > If you agree, I can do the following: > * Close this vote thread > * Upload the "non-RC" Python wheel file to SVN > * Open a new vote thread with both the TestPyPI link and the SVN link > * Update #4220 <https://github.com/apache/polaris/pull/4220> to do the > double build and upload to SVN. > > What do you think? > > Best, > Adnan Hemani > > On Fri, Apr 17, 2026 at 4:23 PM Dmitri Bourlatchkov <[email protected]> > wrote: > > > 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 > > > > > > > > > >
