+1 for a 2.0 branch. Feature specific branches can be created off the 2.0 branch, and should ideally be merged periodically. I would also suggest that we adopt a C-T-R policy [1] for the 2.0 branch until it is at a stable point. Finally, I would assume that it is up to the feature developers to decide whether the feature will maintain backward compatibility or not. 2.0 is an opportunity to break backward compatibility so it would be quite acceptable for some major features to break compatibility. One major question backward compatibility for 2.0 would be Arrow. If we decide we want to have Arrow support, we would probably break backward compatibility in may ways. If we don't do Arrow support in 2.0, we'll probably never do it. We could, of course, do partial support. For reference see the Spark effort [2]
[1] https://www.apache.org/foundation/glossary.html#CommitThenReview [2] https://jira.apache.org/jira/browse/SPARK-26413 On Thu, Feb 28, 2019 at 9:26 AM 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 > > > > > > > > > >
