Hi, wouldn't that be in conflict with Apache release policy [1] ?
[1] http://www.apache.org/legal/release-policy.html On Thu, Apr 25, 2019 at 1:35 AM Alan Myrvold <[email protected]> wrote: > 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 >>>> >>>
