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 > > >
