> While it's not a requirement, >From the experience releasing Hamilton & on the prior discuss thread there was feedback that we should ONLY VOTE ON SOURCE and not on convenience packages if we have the script to generate them programmatically.
Can the Incubator management team please meet to conform to a single definitive opinion on this? Additional complexities we have that ^ should take into consideration: 1. We bundle JavaScript into the convenience package (all are apache 2 compatible licenses). IIRC we don't vote on binaries, right? 2. There are also challenges with us because we will push two pypi packages... Why should we burden everyone with validating all the packages? Please advise. Cheers, Stefan On Wed, Nov 26, 2025 at 7:32 AM Jarek Potiuk <[email protected]> wrote: > I will review it a bit deepr later today/tomorrow, but I agree with PJ. > > > While it's not a requirement, it's generally a good practice to prepare > pypi distributions and upload them to dist as well as sources. If you can > prepare them already in the form that they "will" work when they are > promoted as final candidates (i.e. they should not have rc*) Then you can > directly take later those and upload them to PyPI from "dist" if vote pass > - knowing that things were verified, that signatures and checksums are also > stored. And you do not even have to rebuild it again - you **just** publish > what you already have in SVN. > This way anyone who gets the packages from PyPI can verify if they are "the > same" distributions (binary) and that signatures and checksums are ok - > even if it's not supported by PyPI, they can do it in their pipelines. > Also having **the same** files does not introduce the issue that you vote > on something else than what you publish as public packages for end-user > consumptions. > > This is what we do in Airflow. > > We do not do it (yet) with actual rc packages that we publish in PyPI for > convenience of testing - (i.e. we only publish signatures, and checksums > and artifacts in dist for the would-be-final-if-promoted) distributions > because those are pre-release builds (main difference is that they have rc* > version rather than final) .But we will likely do soon (though these are > really, really, really nice-to-have - those packages are only used for > testing, so it's not as important to vote on them, here we trust that > release manager used the same sources for the rc PyPI pavkages). > > Speaking of which, it would likely be great to publish those rcs in PyPI > for various reasons: > > 1) it tests the upload process, permissions and the like > 2) it allows your users to test it super easily by `pip install --pre` or > direct version specification > 3) it tests if the packages fulfill PyPI criteria and won't be rejected > > I recommend to twine check and upload (with twine check first, and PyPI > upload double check). That avoids problems where you technically **can** > prepare .sdist, .whls from sources, but they are "not good" - we had it few > time in the past that errors in README.md have been rejected only at the > moment of uploading to PyPI (it even passed twine checks) - that was > something about markdown formatting error in the readme as far as I > remember - and really the only check is to attempt to upload it. > > J. > > > On Wed, Nov 26, 2025 at 11:04 AM PJ Fanning <[email protected]> wrote: > > > Most teams provide the pypi files for review. > > > > I'm not involved too closely with Python projects but with Java, you > > can't do an ASF release without providing staged jars for review. They > > are part of the vote. > > I don't know where this pypi exemption has come from and as I say, > > other teams provide files on dist.apache.org for review of pypi > > artifacts. > > > > On Wed, 26 Nov 2025 at 09:51, Stefan Krawczyk <[email protected] > > > > wrote: > > > > > > Yes there's going to be a pypi release of convenience packages. They > can > > be > > > created using the build script that is bundled with the source files. > > This > > > follows the recommendation from the earlier discussion thread that > those > > > are not voted on. > > > > > > On Tue, Nov 25, 2025, 11:54 PM PJ Fanning <[email protected]> wrote: > > > > > > > Is there going to be a pypi release and if so, these files should be > > > > included with the release candidate for review? > > > > > > > > On Wed, 26 Nov 2025 at 08:07, Elijah ben Izzy > > > > <[email protected]> wrote: > > > > > > > > > > Hi all! > > > > > > > > > > This is a call for a vote on releasing Apache Burr > 0.41.0-incubating > > > > > Release Candidate 1. > > > > > > > > > > This release includes the following changes (see CHANGELOG for > > details). > > > > > See all commits since prior release: > > > > > - https://github.com/apache/burr/compare/burr-0.40.2...main > > > > > > > > > > Key changes include: > > > > > - pool-based async PG persister > > > > > - multiple UI updates > > > > > - Apache compatible licenses/build processes > > > > > - bug fixes, typing, etc... > > > > > > > > > > The artifacts for this release candidate can be found at: > > > > > > > > > > > > https://dist.apache.org/repos/dist/dev/incubator/burr/0.41.0-incubating-RC1 > > > > > > > > > > The Git tag to be voted upon is: v0.41.0 > > > > > > > > > > The release hash is a95c7c3f1425db382b367b0d4f888704ea2939f9 > > > > > > > > > > Release artifacts are signed with the following key: > > > > > BB8B72B34AB9A664A109AA17A76CF4C80E4E5355 > > > > > The KEYS file is available at: > > > > > https://downloads.apache.org/incubator/burr/KEYS > > > > > > > > > > Please download, verify, and test the release candidate. For > testing > > use > > > > > your best judgement. The following may suffice: > > > > > > > > > > 1. Build/run the UI following the instructions in scripts/README.md > > > > > 2. Run the tests in tests/ > > > > > 3. Import into a jupyter notebook and play around > > > > > > > > > > The vote will run for a minimum of 72 hours. > > > > > Please vote: > > > > > > > > > > [ ] +1 Release this package as Apache Burr 0.41.0-incubating > > > > > [ ] +0 No opinion > > > > > [ ] -1 Do not release this package because... (Please provide a > > reason) > > > > > > > > > > Checklist for reference: > > > > > [ ] Download links are valid. > > > > > [ ] Checksums and signatures. > > > > > [ ] LICENSE/NOTICE files exist > > > > > [ ] No unexpected binary files > > > > > [ ] All source files have ASF headers > > > > > [ ] Can compile from source > > > > > > > > > > On behalf of the Apache Burr PPMC, > > > > > > > > > > Elijah ben Izzy ([email protected]) > > > > > > >
