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 >
