TestPyPi certainly seems useful to practice the release process, and avoid mistakes with it.
However, I don't think that it is a substitute for a .devN release, which (in my mind) is meant to give the users something to use until we get all our ducks in a row to do a proper 1.0 release. The primary user in this case would be Hue, which needs the new features, and is currently mirroring our dev sources into their own repo. (TBH, that's their normal modus operandi anyway, but for their Python 3 version, they'd like to switch to PyPI modules) To use a dev package, the users have to explicitly specify the exact development version, (or go all-out, and use development versions of all packages), so there is no chance of them accidentally upgrading from a stable release. Making them specify another repo as well to install a dev release sounds like too much to me. If on the other hand we plan on releasing the current state of PhoenixDB as 1.0 soon (like in month), and then do frequent-ish releases as new features/fixes are (hopefully) added, then we can skip the dev releases altogether. The Phoenix norm so far is more like yearly releases (if we are lucky). regards István On Mon, Jun 15, 2020 at 7:08 PM Josh Elser <[email protected]> wrote: > Did a little searching.. > > * Found a 2011 blog post from sqlalchemy which said (as a project) they > would not post devN releases to pypi > * There's a TestPyPi [1] instead which seems to be for staging work. > > Could we play with staging there? And then push to pypi (real) after we > do a normal vote? > > I think we can keep our python release super-low friction :) > > [1] https://packaging.python.org/guides/using-testpypi/ > > On 6/15/20 1:02 PM, Josh Elser wrote: > > Hey Istvan, > > > > Great of you to drive this work! > > > > I do have one concern about pushing the dev releases to PyPi (I'm > > assuming that's what you mean). I understand that in the Python world a > > "dev" release indicates that this isn't an "official" release [1]. > > > > At the ASF, you're correct that we, developers, are empowered to make > > "builds" of our product(s) for the sake of our development. There is a > > clear line when that "build" is published in a location to which a user > > may find it and begin to use it. There has been at least one example in > > recent memory of a project which made "developer only releases" without > > proper voting, but published them in a high-visibility location and > > (inadvertently or intentionally) circumvented the ASF release > requirements. > > > > My biggest concern is: would a user who ran a `pip install phoenixdb` > > after we make a devN release get the last-stable release (0.7) or the > > new devN release? If they would get the dev release, does PyPi give us > > any flexibility to prevent this from happening? I believe that we should > > consider publishing to the "official" location should be treated as a > > release if it means that a user could begin to use it with "low > friction". > > > > - Josh > > > > > > [1] https://www.python.org/dev/peps/pep-0440/#id24 > > > > On 6/12/20 7:11 AM, Istvan Toth wrote: > >> Hi! > >> > >> Even though we have adopted the PhoenixDB driver in 2018, there hasn't > >> been > >> much activity on it, and the version available on PyPI is still the > >> old 0.7 > >> release by Lukas. > >> > >> Recently I have worked on it quite a bit, adding fixes and new features, > >> and adopting the partial SQLAlchemy driver from pyPhoenix, thus enabling > >> Hue support. > >> > >> I plan to start releasing the driver publicly on PyPI. Lukas has kindly > >> shared control of the PyPI phoenixdb project with us, so we are good > >> to go. > >> > >> The short-term plan is to release 1.0.0.dev0 and later 1.0.0.devN > >> releases > >> from the current HEAD of phoenix-queryserver. As these will be dev > >> releases, I am not planning to follow a formal release process for > these. > >> > >> When and how to release 1.0.0 final, and the versioning scheme/process > to > >> use after that are still not finalized. > >> > >> Please join the discussion here, or in > >> https://issues.apache.org/jira/browse/PHOENIX-5939 if you have any > >> questions or suggestions! > >> > >> regards > >> Istvan > >> > -- *István Tóth* | Staff Software Engineer [email protected] <https://www.cloudera.com> [image: Cloudera] <https://www.cloudera.com/> [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera on LinkedIn] <https://www.linkedin.com/company/cloudera> <https://www.cloudera.com/> ------------------------------
