The Beam guide looks interesting, we could certainly borrow from it. I'm fine with your suggested process. Here's my interpretation of it:
- No dev releases on PyPI - Decoupling PhoenixDB versioning from PQS versioning - Making a proper minor/patch release when important features/fixes land - Testing the release process /making RC releases on TestPyPI One more detail that we haven't discussed yet: The previous PyPI releases were source packages. I suggest that we can keep releasing PhoenixDB as a source package, as it is pure python. Istvan On Tue, Jun 16, 2020 at 3:32 AM Josh Elser <[email protected]> wrote: > ASF releases do not have to be on the order of years. As long as we have > three people to vote, we can do releases as often as we'd like. The > lower-bound on release cadence is probably on the order of "weeks" (as > opposed to days) but that's primarily limited by bandwidth of our > volunteers :) > > Anyways, if that's the major worry, let's just push to doing proper > votes. We should not have the problem in having people turn out to vote. > > I'll put L&N review to the top of my list to do (my) tomorrow morning. > Sorry I haven't gotten to it yet. > > On 6/15/20 1:42 PM, Istvan Toth wrote: > > 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 > >>>> > >> > > > > >
