+1 for option a. I think backward compatibility can be handled via temp options, for interfaces since we use Java 8 default methods can be used. In case of more extreme cases, they should be postponed till 2.0 branch is created.
Kind regards, Arina > On Feb 28, 2019, at 7:25 PM, Pritesh Maker <pma...@mapr.com> wrote: > > I think option (a) is better in terms of maintaining branches. With option > (a) how do we handle a situation where one of these features breaks > backward compatibility or deprecates some functionality? > > Pritesh > > On Wed, Feb 27, 2019 at 4:23 PM Abhishek Girish <agir...@apache.org> wrote: > >> My opinion would be option (a) as well. It's easier to maintain a single >> master branch. With a separate v2 branch, it's twice the effort to test >> common commits going in (either directly or via later via rebase). >> >> On Wed, Feb 27, 2019 at 12:40 PM Aman Sinha <amansi...@gmail.com> wrote: >> >>> My personal preference would be option (a) as much as possible until we >>> get to a situation where it is getting too unwieldy at which point we >>> re-evaluate. >>> >>> Aman >>> >>> On Wed, Feb 27, 2019 at 12:35 PM Aman Sinha <amansi...@gmail.com> wrote: >>> >>>> Hi Drill devs, >>>> There are couple of ongoing projects - Resource Manager and the Drill >>>> Metastore - that are relatively large in scope. Intermediate PRs will >> be >>>> created for these (for example, there's one open for the metastore [1]. >>>> Another one for the RM [2]. These don't currently break existing >>>> functionality, so they have been opened against master branch. >>>> >>>> The question is, for future PRs, would it make sense to create a >>> separate >>>> Drill 2.0 branch ? There are pros and cons. Separate branch would >> allow >>>> development on these features to proceed at a faster pace without >>>> disrupting others. However, in Drill we typically have only created a >>>> separate branch close to the release, not up-front. It simplifies >>> testing >>>> and maintenance to have a unified master branch. >>>> >>>> Another option is feature specific branch. >>>> >>>> What do people think about the 3 options: >>>> a) Merge intermediate PRs into Apache master as long as they don't >>> break >>>> existing functionality. In some cases, temporary config options may be >>>> used to enable new functionality for unit testing. >>>> b) Create a Drill-2.0 branch which will be work-in-progress and be >>>> periodically sync-ed with master branch. Code reviews will be done >>> against >>>> this branch. >>>> c) Have a feature specific branch - e.g for RM, for Metastore etc. >> such >>>> that collaborators can do peer reviews and merge intermediate commits. >>>> These branches will also need to be periodically sync-ed with the >> master >>>> branch. >>>> >>>> Please share your choice of one of these options and any additional >>>> thoughts. >>>> >>>> [1] https://github.com/apache/drill/pull/1646 >>>> [2] https://github.com/apache/drill/pull/1652 >>>> >>> >>
