Sorry " should be *not *to encourage the projects to make it easy for anyone to install and test the release" -> "should be to encourage the projects to make it easy for anyone to install and test the release"
On Thu, Jan 9, 2025 at 1:06 PM Jarek Potiuk <ja...@potiuk.com> wrote: > 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. > > >
