Great idea. I like the RC candidates to follow as much as the release artifact process as possible.
On Wed, Apr 24, 2019 at 3:27 PM Ahmet Altay <[email protected]> wrote: > To clarify my proposal, I am proposing publishing to the production pypi > repository with an rc tag in the version. And in turn allow users to depend > on beam's rc version + all the other regular dependencies users would have > directly from pypi. > > Publishing to test pypi repo would also be helpful if test pypi repo also > mirrors other packages that exist in the production pypi repository. > > On Wed, Apr 24, 2019 at 3:12 PM Pablo Estrada <[email protected]> wrote: > >> 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. >> > > I also don't know who owns beam package in test pypi repo. Does > anybody know? > > >> >> 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 <[email protected]> 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 >>> >>
