As I explained in the original email, ZooKeeper 3.5 is now at "beta" and will soon be the main version. CURATOR-3.0 is our branch that matches ZooKeeper 3.5 so it too needs to be master. That's the reason for the change.
How many additional versions of CURATOR-2.0 we do is entirely up to us. CURATOR-409/CURATOR-410 as examples of changes that also apply to CURATOR-2.0. Cherry-pick is one option. A git patch/apply would also work. -JZ > On May 8, 2017, at 7:50 AM, Scott Blum <[email protected]> wrote: > > We should definitely be very clear on the goals before trying to pick a > specific technical strategy! > > If 2.0 is basically "done" except for bugfixes, then the best strategy is > probably to just do everything on master (3.0) and only backport / > cherry-pick specific bugfixes. I'm assuming that was the underlying rational > for calling 3.0 master? > > > On Mon, May 8, 2017 at 12:23 AM, Jordan Zimmerman <[email protected] > <mailto:[email protected]>> wrote: > In this case I think the PRs were made against master. But, they both apply > to CURATOR-2.0. > > Another possibility is that we sunset CURATOR-2.0 and just say - time to move > on CURATOR-2.0 is what it is. > > -JZ > > > On May 8, 2017, at 6:22 AM, Cameron McKenzie <[email protected] > > <mailto:[email protected]>> wrote: > > > > The PRs were presumably made against the 3.0 baseline? I guess if it's a > > 3.0 specific fix it should just be merged to master. If it's a 2.0 fix then > > it should be merged into 2.0 and then merged up to master if appropriate. > > > > On Mon, May 8, 2017 at 2:17 PM, Jordan Zimmerman > > <[email protected] <mailto:[email protected]> > >> wrote: > > > >> For example, I just merged CURATOR-409/CURATOR-410 - a simple merge of > >> those two into CURATOR-2.0 would bring in all the CURATOR-3.0 changes. > >> > >> -JZ > >> > >>> On May 8, 2017, at 6:12 AM, Cameron McKenzie <[email protected] > >>> <mailto:[email protected]>> > >> wrote: > >>> > >>> Can we still apply patches (where appropriate) to CURATOR-2.0 and merge > >>> into master? Cherry picking seems very manual and error prone (at least > >>> based on my minimal Git experience). > >>> cheers > >>> > >>> On Mon, May 8, 2017 at 2:09 PM, Jordan Zimmerman < > >> [email protected] <mailto:[email protected]> > >>>> wrote: > >>> > >>>> Folks, > >>>> > >>>> Now that CURATOR-3.0 is master, how should we deal with keeping > >>>> CURATOR-2.0 in sync. It's no longer possible to do simple merges. > >> Should we > >>>> cherry-pick changes into CURATOR-2.0? Should we require separate PRs for > >>>> changes to each branch? > >>>> > >>>> Scott, you're our resident git expert. Any best practices to apply here? > >>>> > >>>> -Jordan > >> > >> > >
