Just a small thing to add - while we are releasing RCs, I think the right approach should be not to encourage the projects to make it easy for anyone to install and test the release - which does not automatically mean to publish RC in the same way the final candidate is published. The key here is to let the users know that there is a candidate and encourage them to test it. I think it has more nuances than publishing to Maven/ PyPI etc. - and PMCs should choose their own ways and encourage their "dev community" (not end users mind you - those users might be misled into thinking this is the final release!) to test it.
There are many ways how this can be done: * Airflow is indeed publishing RC candidates in PyPI (PyPI has a great distinction between pre-release and final candidates and users cannot mistake them for final versions, they need to explicitly install RC candidates) and we invite contributors to test the releases via GitHub issue (automated) where we mark the involved contributors: example here - https://github.com/apache/airflow/issues/45148 - we usually have at least 60% "success" rate - i.e. more than half of the users involved are willing to take the RCs for a spin, install it and test it (and confirm it works or report issues). This sustainably works for 3-4 years now. * However, quite recently in the Python ecosystem at least where the Python Community standardised packaging and build backend/front-end approach - it is a very common practice to use GitHub branches to install the software. There is a way to do it it in a standard way and more often than not when we find and report (or comment) an issue in a dependent library, they create a PR and ask everyone to test it from the branch - an example of it recently where we found a problem in Pygments and they created a PR fixing it - issue here https://github.com/pygments/pygments/issues/2834, PR in Airflow testing the change in PR here: https://github.com/apache/airflow/pull/45416/files (basically replacing "pygments>=2.0.1,!=2.19.0" with "pygments @ git+ https://github.com/pygments/pygments.git@a9858663ed85219ed7475f5877b22b9cb49f660f";. This is a very efficient way of testing - because you can test the fix not when all the burden of release preparation and rc candidate preparation is done, but way before, even way before the PR with fix is merged. This is something we are actually going to encourage more - currently our 90+ providers in our monorepo are not installable via GIT URL, but we are implementing restructuring to make it possible - so that you can install any of our packages directly from our monorepo github repo - specifying the package you want to install, URL and commit-ish git reference. So if we want to add something about policies/best practices - we should rather describe the "INTENTION" to have RC (or even PR!) candidates being easily available to install and test, but how PMCS turn that into practice - should be up to them. J.
