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