I think this is a great idea. A way of doing it for python would be by using the test repository for PyPi[1], and that way we would not have to do an official PyPi release, but still would be able to install it with pip (by passing an extra flag), and test.
In fact, there are some Beam artifacts already in there[2]. At some point I looked into this, but couldn't figure out who has access/the password for it. In short: +1, and I would suggest using the test PyPi repo to avoid publishing to the main PyPi repo. Best -P. [1] https://test.pypi.org/ [2] https://test.pypi.org/project/apache-beam/ On Wed, Apr 24, 2019 at 3:04 PM Ahmet Altay <al...@google.com> wrote: > Hi all, > > What do you think about the idea of publishing pre-release artifacts as > part of the RC emails? > > For Python this would translate into publishing the same artifacts from RC > email with a version like "2.X.0rcY" to pypi. I do not know, but I am > guessing we can do a similar thing with Maven central for Java artifacts as > well. > > Advantages would be: > - Allow end users to validate RCs for their own purposes using the same > exact process they will normally use. > - Enable early-adaptors to start using RC releases early on in the > release cycle if that is what they would like to do. This will in turn > reduce time pressure on some releases. Especially for cases like someone > needs a release to be finalized for an upcoming event. > > There will also be disadvantages, some I could think of: > - Users could request support for RC artifacts. Hopefully in the form of > feedback for us to improve the release. But it could also be in the form of > folks using RC artifacts for production for a long time. > - It will add toil to the current release process, there will be one more > step for each RC. I think for python this will be a small step but > nevertheless it will be additional work. > > For an example of this, you can take a look at tensorflow releases. For > 1.13 there were 3 pre-releases [1]. > > Ahmet > > [1] https://pypi.org/project/tensorflow/#history >