Re: Proposal: Create v2 branch to work on breaking changes

A number of the vector problems are an issue for the Java client but not the c client since the c client doesn't support complex or union types yet. Agree on your other points: - We need to get to rolling upgrades. (Note that I suggest that we try to get to "minor" compatibility for Drillbit

Re: Proposal: Create v2 branch to work on breaking changes

Thanks for putting this doc together Jacques. This gives us a clear framework for discussion. Just as a clarification (I haven't yet been able to do more than glance at the doc), for 2.0, I was suggesting client-server compatibility not drillbit-drillbit compatibility. It seems some of the items

Re: Proposal: Create v2 branch to work on breaking changes

Hi Jacques, Thanks for keeping the list in the loop. I'll be on the lookout for this sanitized list. George On Wed, Apr 13, 2016 at 11:40 AM, Jacques Nadeau wrote: > For anyone following this thread, some of the people here reached out to me > privately to better detail

Re: Proposal: Create v2 branch to work on breaking changes

For anyone following this thread, some of the people here reached out to me privately to better detail some concerns that they don't feel comfortable sharing publicly. I'm work with them to come up with a sanitized way to share the specific requirements that they are seeing so that we can come to

Re: Proposal: Create v2 branch to work on breaking changes

A general policy shouldn't hold up a specific decision. Even after we establish a guiding policy, there will be exceptions that we will consider. I'm looking for concrete counterpoint to the cost of maintaining backwards compatibility. That being said, I have put together an initial proposal of

Re: Proposal: Create v2 branch to work on breaking changes

Makes sense to postpone the debate : ) Will Look forward for the proposal. On Tuesday, April 12, 2016, Zelaine Fong wrote: > As we discussed at this morning's hangout, Jacques took the action to put > together a strawman compatibility points document. Would it be better to

Re: Proposal: Create v2 branch to work on breaking changes

As we discussed at this morning's hangout, Jacques took the action to put together a strawman compatibility points document. Would it be better to wait for that document before we debate this further? -- Zelaine On Tue, Apr 12, 2016 at 4:39 PM, Jacques Nadeau wrote: > I

Re: Proposal: Create v2 branch to work on breaking changes

I agree with Paul, too. Perfect compatibility would be great. I recognize the issues that a version break could cause. These are some of the issues that I believe require a version break to address: - Support nulls in lists. - Distinguish null maps from empty maps. - Distinguish null arrays from

Re: Proposal: Create v2 branch to work on breaking changes

I agree with Paul. Great points. I would also add the partners aspect to it. Majority of Drill users use it in conjunction with a BI tool. -Neeraja On Tue, Apr 12, 2016 at 3:34 PM, Paul Rogers wrote: > Hi Jacques, > > My two cents… > > The unfortunate reality is that

Re: Proposal: Create v2 branch to work on breaking changes

Hi Jacques, My two cents… The unfortunate reality is that enterprise customers move slowly. There is a delay in the time it takes for end users to upgrade to a new release. When a third-party tool must also upgrade, the delay becomes even longer. At a high level, we need to provide a window

Re: Proposal: Create v2 branch to work on breaking changes

>>What I am suggesting is that we need to maintain backward compatibility with a defined set of 1.x version clients when Drill 2.0 version is out. I'm asking you to be concrete on why. There is definitely a cost to maintaining this compatibility. What are the real costs if we don't? -- Jacques

Re: Proposal: Create v2 branch to work on breaking changes

Jacques can you elaborate on what you mean by 'internal' implementation changes but maintain external API. I thought that changes that are being discussed here are the Drill client library changes. What I am suggesting is that we need to maintain backward compatibility with a defined set of 1.x

Re: Proposal: Create v2 branch to work on breaking changes

Thanks for bringing this up. BI compatibility is super important. The discussions here are primarily about internal implementation changes as opposed to external API changes. From a BI perspective, I think (hope) everyone shares the goal of having zero (to minimal) changes in terms of ODBC and

Re: Proposal: Create v2 branch to work on breaking changes

Sorry for coming back to this thread late. I have some feedback on the compatibility aspects of 2.0. We are working with a variety of BI vendors to certify Drill and provide native connectors for Drill. Having native access from BI tools helps with seamless experience for the users with

Re: Proposal: Create v2 branch to work on breaking changes

I'm going to take this as lazy consensus. I'll create the branch. Once created, all merges to the master (1.x branch) should also go to the v2 branch unless we have a discussion here that they aren't applicable. When committing, please make sure to commit to both locations. thanks, Jacques --

Re: Proposal: Create v2 branch to work on breaking changes

Hi All, 2.0 is a good opportunity to enhance our ZK information. See DRILL-4543: Advertise Drill-bit ports, status, capabilities in ZooKeeper. This change will simplify YARN integration. This enhancement will change the “public API” in ZK. To Parth’s point, we can do so in a way that old

Proposal: Create v2 branch to work on breaking changes

There are some changes that either have reviews pending or are in progress that would require breaking changes to Drill core. Examples Include: DRILL-4455 (arrow integration) DRILL-4417 (jdbc/odbc/rpc changes) DRILL-4534 (improve null performance) I've created a new 2.0.0 release version in JIRA