Hey David, I just checked in pypi and didn't see the new version. You still planning on doing this?
Thx, J-D On Tue, Mar 15, 2016 at 10:43 AM, David Alves <[email protected]> wrote: > Thanks, Wes. > Ok, I'll bump the version to 0.2.0 and release what we have, which hasn't > changed since the last kudu release. > If we go a few releases without needing different releases for the python > client then we can make it match. > I'll do the release to pypi today. > > -david > > On Tue, Mar 15, 2016 at 10:39 AM, Wes McKinney <[email protected]> wrote: > > > I'm fine with releasing them at the same time, but I would propose > > that we use separate version numbering to avoid potential confusion in > > the future should the releases decouple. If different version numbers > > cause some concern, then using the same number for now is OK as long > > as we aren't closing the door on faster releases (for example: urgent > > bug fixes — I suspect that the Python client will in general have > > strictly more bugs than the C++ client) in the future. > > > > On Tue, Mar 15, 2016 at 10:32 AM, David Alves <[email protected]> > > wrote: > > > If we're bumping and if everyone agrees I propose we just bum the > version > > > to match kudu and, for now at least, go with the plan of releasing the > > > python client at the same time as the rest of kudu. > > > Wes: you ok with that? > > > > > > -david > > > > > > On Mon, Mar 14, 2016 at 12:40 PM, Todd Lipcon <[email protected]> > wrote: > > > > > >> So, right now our PyPI package is incompatible with the latest > releases > > >> due to some client ABI changes. For now, I'd propose we bump the > > version to > > >> 0.2.0. > > >> > > >> Regarding release cadence, keep in mind that we need to do a vote > before > > >> any public release (even if it's just the python client). So, I'm not > > sure > > >> how realistic it is to have a significantly faster python release > > cadence > > >> than the rest of the software. > > >> > > >> -Todd > > >> > > >> On Wed, Mar 9, 2016 at 4:27 PM, Adar Dembo <[email protected]> wrote: > > >> > > >>> Wes and I discussed this very issue in > > >>> http://gerrit.cloudera.org:8080/#/c/1593 two months ago. > > >>> > > >>> On Wed, Mar 9, 2016 at 4:25 PM, Casey Ching <[email protected]> > > wrote: > > >>> > > >>> > I’d also go with separating the version numbers. Hopefully > eventually > > >>> the > > >>> > client api will be stable and won’t change much, then a new Kudu > > release > > >>> > won’t require a python release. If the version are made to match, > > there > > >>> > should come a time when the python version number needs to be > bumped > > >>> just > > >>> > to keep the versions in sync though no actual python/client changes > > were > > >>> > made. > > >>> > > > >>> > If you are worried about client/server compatibility, maybe there > is > > >>> > something that can be done such that the client/server verify that > > they > > >>> are > > >>> > in fact compatible through some api call. > > >>> > > > >>> > Casey > > >>> > On March 9, 2016 at 4:10:40 PM, David Alves ([email protected] > ) > > >>> wrote: > > >>> > > > >>> > We intend to produce Kudu releases every couple of months. > > >>> > It's also worth noting that while we can keep a different release > > >>> cadence > > >>> > for the python client we still need to go through a vote and do a > > proper > > >>> > release. > > >>> > Do you feel like its worth the additional work to increase the > > cadence > > >>> or > > >>> > do you feel that 2 months is likely enough? > > >>> > As an alternative we could have a primary plan to make the > > major/minor > > >>> > versions match and release in the same cadence, but reserve the > right > > >>> to do > > >>> > ad-hoc micro releases occasionally. > > >>> > Thoughts? > > >>> > > > >>> > Best > > >>> > David > > >>> > > > >>> > On Wed, Mar 9, 2016 at 3:56 PM, Wes McKinney <[email protected]> > > wrote: > > >>> > > > >>> > > Since I expect the Python client to evolve faster from a user > > >>> > > perspective (as opposed to Kudu core, where users will see > > basically a > > >>> > > stable client API and wire protocol in general) I'd prefer to > make > > >>> > > Python releases separate from Kudu major/minor releases. For > > example, > > >>> > > sometime in the next couple months I would like to add low-level > > >>> > > (C-level) interoperability between pandas, NumPy, and Kudu. It > > would > > >>> > > be nice to be able to ship this basically as soon as it's > > available in > > >>> > > trunk. This is somewhat independent from the version numbering > > >>> > > question, but it would probably be better for the Python client > and > > >>> > > interop tools to have their own version number. If the Kudu > > committers > > >>> > > feel otherwise, it's not an issue -- some of this depends on the > > >>> > > expected release cadence of Kudu itself. > > >>> > > > > >>> > > best, > > >>> > > Wes > > >>> > > > > >>> > > On Wed, Mar 9, 2016 at 3:49 PM, David Alves < > [email protected] > > > > > >>> > wrote: > > >>> > > > Hi All > > >>> > > > > > >>> > > > We'll need to release a new version of the python client to > pypi > > >>> and we > > >>> > > > were discussing versioning strategies. > > >>> > > > Currently the python's client version does not match the > version > > of > > >>> the > > >>> > > > c++ client/server (0.1.0 versus 0.7.1) and we can either stick > > with > > >>> > that > > >>> > > > and keep different versions, or change it to match the latest > > Kudu > > >>> > > release. > > >>> > > > Making the versions match would have the advantage of making it > > >>> clear > > >>> > > to > > >>> > > > developers if the server/client versions match or not, which > > might > > >>> help > > >>> > > > weeding out compatibility bugs. On the other hand keeping > > different > > >>> > > > versions would likely make our lives easier if we want to > release > > >>> the > > >>> > > > python client at a different cadence of regular Kudu releases. > > >>> > > > What do people think? > > >>> > > > > > >>> > > > Best > > >>> > > > David > > >>> > > > > >>> > > > >>> > > >> > > >> > > >> > > >> -- > > >> Todd Lipcon > > >> Software Engineer, Cloudera > > >> > > >
