To get the ball rolling on this I put up a series of patchsets (1 <https://gerrit.cloudera.org/#/c/3736/>, 2 <https://gerrit.cloudera.org/#/c/3737/>, 3 <https://gerrit.cloudera.org/#/c/3738/>). No attempt was made at maintaining backwards compatibility with applications. In-flight changes to the Java client should in theory rebase cleanly against these changes (except perhaps part 3, but it is optional).
- Dan On Wed, Jun 8, 2016 at 11:22 AM, Mike Percy <[email protected]> wrote: > Todd you bring up a good point about the wire compatibility being > maintained. > > Since PODLINGNAMESEARCH-93 has now been approved, and we get to keep the > Apache Kudu name (yay!) then I'm +1 with just renaming the packages to > org.apache.kudu. > > Mike > > On Wed, Jun 1, 2016 at 1:23 PM, Todd Lipcon <[email protected]> wrote: > > > I'm also -0 on backwards compatibility shims. We are a young project > with a > > small install base, and the upgrade here is just find and replace. Given > > our good wire compatibility, people can do so at their own pace. > > > > Todd > > On Wed, Jun 1, 2016 at 11:56 AM, Jean-Daniel Cryans <[email protected] > > > > wrote: > > > > > So, in your opinion Mike, should we do the change if > PODLINGNAMESEARCH-93 > > > is solved within a reasonable time frame before 1.0? > > > > > > > I think we should do it in a backwards compatible way, deprecate the old > > names, and delete them after a couple of releases. If it's just a few > hours > > of someone's time then I think it's a no brainer to just do a facade. > > > > That said, if we're talking a week or weeks of work to do it right then > I'm > > +0 to renaming and breaking backcompat before 1.0 and -0 for leaving them > > not renamed for the forseeable future. I haven't tried to scope the > effort. > > > > Mike > > >
