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
