Ashs, Stefan, more than happy to upload. Will take a small bit (hopefully tonight) as I want to make sure I get it right before doing so, but I have all the built files as well as the right scripts to make it easy to do so (manually, in a trusted manner).
This will make testing simpler for the PMC members. On 2025/11/26 17:32:24 Elijah ben Izzy wrote: > Uploading the wheel is not a huge amount of work. But yes, they are more than > "source" -- I.E. they're the built package (binary). If we do this with java > then doing it with python isn't crazy. > > By "bundle javascript" it's not "source" it's a minified source -- a static > page that's served. > > Will await your opinions. Release is easier if we have the wheel as well, we > can (I think) just release the same binary. > > On 2025/11/26 17:26:23 Stefan Krawczyk wrote: > > > 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]) > > > > > > > > > > > > > > > >
