Hi It's what I proposed in my vote email: "Maybe we could include apache_polaris-x.y.z.tar.gz on dist.apache.org in future releases, similar to what we do for Helm."
I think it's a clean approach. Regards JB On Sat, Apr 18, 2026 at 4:32 AM Dmitri Bourlatchkov <[email protected]> wrote: > 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 > > > > > > > > > > > > > > >
