Re Compatibility: I actually don't even think 1.0 clients work with 1.6 server, do they?
I would probably decrease the cross-compatibility requirement burden. A nice goal would be cross compatibility across an extended series of releases. However, given all the things we've learned in the last year, we shouldn't try to maintain more legacy than is necessary. As such, I propose that we consider the requirement of 2.0 to be: 1.lastX works with 2.firstX. (For example, if 1.8 is the last minor release of the 1.x series, 1.8 would work with 2.0.) This simplifies testing (we don't have to worry about things like does 1.1 work with 2.3, etc) and gives people an upgrade path as they desire. This also allows us to decide what pieces of the compatibility shim go in the 2.0 server versus the 1.lastX client. (I actually lean towards allowing a full break between v1 and v2 server/client but understand that that level or coordination is hard in many organizations since analysts are separate from IT). Hopefully, what I'm proposing can be a good compromise between progress and deployment ease. Thoughts? Re: Branches/Dangers Good points on this Julian. How about this: - small fixes and enhancements PRs should be made against v1 - new feature PRs should be made against v2 - v2 should continue to always pass all precommit tests during its life - v2 becomes master in two months I definitely don't want to create instability in the v2 branch. The other option I see is we can only do bug fix releases and branch the current master into a maintenance branch and treat master as v2. Other ideas? -- Jacques Nadeau CTO and Co-Founder, Dremio On Sat, Mar 26, 2016 at 6:07 PM, Julian Hyde <[email protected]> wrote: > Do you plan to be doing significant development on both the v1 and v2 > branches, and if so, for how long? I have been bitten badly by that pattern > in the past. Developers put lots of unrelated, destabilizing changes into > v2, it look longer than expected to stabilize v2, product management lost > confidence in v2 and shifted resources back to v1, and v2 never caught up > with v1. > > One important question: Which branch will you ask people to target for > pull requests? v1, v2 or both? If they submit to v2, and v2 is broken, how > will you know whether the patches are good? > > My recommendation is to choose one of the following: (1) put a strict time > limit of say 2 months after which v2 would become the master branch (and v1 > master would become a maintenance branch), or (2) make v2 focused on a > particular architectural feature; create multiple independent feature > branches with breaking API changes if you need to. > > Julian > > > > On Mar 26, 2016, at 1:41 PM, Paul Rogers <[email protected]> wrote: > > > > 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 clients work - as long as a Drill-bit uses > default ports. > > > > I’ve marked this JIRA as a candidate for 2.0. > > > > Thanks, > > > > - Paul > > > >> On Mar 24, 2016, at 4:11 PM, Parth Chandra <[email protected]> wrote: > >> > >> What's our proposal for backward compatibility between 1.x and 2.x? > >> My thoughts: > >> Optional - Allow a mixture of 1.x and 2.x drillbits in a cluster. > >> Required - 1.x clients should be able to talk to 2.x drillbits. > >> > >> > >> > >> On Thu, Mar 24, 2016 at 8:55 AM, Jacques Nadeau <[email protected]> > wrote: > >> > >>> 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 and moved these tasks > to > >>> that umbrella. > >>> > >>> I'd like to propose a new v2 release branch where we can start > >>> incorporating these changes without disrupting v1 stability and > >>> compatibility. > >>> > >>> > >>> -- > >>> Jacques Nadeau > >>> CTO and Co-Founder, Dremio > >>> > > > >
