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
