yihua opened a new issue, #758: URL: https://github.com/apache/hudi-rs/issues/758
Nothing in the release process checks the artifacts a release tag publishes to crates.io and pypi.org. `verify_src_release.sh` covers the source release, which is the ASF release proper, but says nothing about the convenience binaries that almost everyone actually installs. The only coverage is two manual lines in the VOTE email template asking each voter to `pip install` and `cargo add`. That gap is how `0.5.0-rc.1` shipped. The manylinux publish job failed while the others had already uploaded, so the version exists on crates.io and on PyPI with the macOS and Windows wheels, and with no Linux wheel and no sdist at all. Nothing surfaced it, because the release manager's only signal was that the workflow had run. A script run between the tag push and the VOTE thread would close this: check that all three crates are on crates.io at the version, that every platform the release workflow builds is on pypi.org along with the sdist, and that the wheel installs in a clean environment and reads a table once loaded. The last part matters on its own, since the rocksdb bindings come from the build container's libclang and bad bindings surface on import or first read rather than at compile time. crates.io does not allow re-publishing a version, so a gap found this way means starting a new release candidate. Finding it before the vote rather than during it is the difference between one wasted RC number and a wasted vote. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
