FYI: ---------- Forwarded message --------- From: Dave Fisher <w...@apache.org> Date: Thu, Jan 9, 2025 at 10:18 AM Subject: Re: [DISCUSS] Consensus to make release candidates publicly accessible during the voting period To: <memb...@apache.org>
Hi Tison, There is an active effort to improve the ASF Release process which is now called Apache Trusted Release. The Foundation is about to contract a Senior Engineer, Tooling in order to work on this project. A major goal is to ease the whole release process and make SBOMs and other attestations simple. We will be looking at packagers like Maven Central, PyPi, …. I’ll have more details about how to participate in this major Tooling effort by February 1. Meanwhile we have Slack channels #tooling-discuss, and one which will be renamed or moved shortly but is currently #artifact-platform-dev Best Regards, Dave, with VP, Tooling hat. > On Jan 9, 2025, at 2:07 AM, tison <wander4...@gmail.com> wrote: > > Hi, > > I'd like to establish a consensus to explicitly allow making release > candidates publicly accessible during the voting period. > > This should be an existing exercise that the source code of release > candidates is available on dist.apache.org, e.g., [1]. > > [1] > https://dist.apache.org/repos/dist/dev/flink/flink-connector-jdbc-3.1.1-rc1/ > > The situation I'd like to highlight here is that, nowadays verifiers > would find it more convenient to pull the release candidate from a > central repository, like Maven Central, PyPI, crates.io, etc. > > I don't know if other projects release versions like 1.0.3-rc.1 to > those repositories during the voting period, but I know a few projects > won't do that before a formal release is cut. This actually harms the > verification the release candidate could receive. > > Making a release candidate version on those repositories should be the > same as publishing the source code to dist.apache.org/repos/dist/dev > with an RC tag. So, I'd establish a consensus to allow doing so > explicitly. > > For example, when Apache Foo (assumed Rust project) is releasing > 1.0.3, the RM could release a 1.0.3-rc.1 version to crates.io, so that > users can simply bump the version to 1.0.3-rc.1 to test it out and > give feedback. These versions would be well-known as under-verifying > status instead of releases endorsed by a TLP PMC. > > So does PyPI and Maven Central (rather than making stagingRepositories > only, which is hard to test for developers unfamiliar with it). > > Some background: > > We require a 72 hours period before calling a formal release. I heard > and experienced that a lot of new developers won't test the release > (candidate) before they are available on those common central > repositories, which, in some way, gives the impression that the ASF > releases slowly. This is, of course, not true. > > By allowing developers to test RC on the central repositories and > establish proper assumptions between a formal release and a release > candidate corresponding to the version tag, we can reduce the friction > of the development workflow that new developers are familiar with. > > Looking forward to your feedback and I'd like to know how other TLPs do. > > Best, > tison.
