Looks like Drill Metastore will not break backward compatibility. Therefore I think as long as this is true, (a) option will be preferable for changes related to Drill Metastore
Kind regards Vitalii On Thu, Feb 28, 2019 at 7:26 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 > > > > > > > > > >
