Cherry-pick is basically an "on the rails" version of patch+apply. Sounds like we should just do all development on master, and cherry pick individual bugfixes to CURATOR-2.0.
The one caveat to that approach, however, is that it works a lot better if you merge+squash changes when you commit to master rather than creating traditional git merge commits on master. The company I worked for switched to merge+squash a while back when Github started offering it from the pull request UI, and it's been great. The history is much more sane to digest, you don't end up with all of the "development" iterations polluting your history forever, and single every change is a single logical commit it's easy to cherry-pick. On Mon, May 8, 2017 at 6:40 AM, Jordan Zimmerman <[email protected] > wrote: > 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]> 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]> >> 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] >> >> 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]> >> >> 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] >> >>>> 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 >> >> >> >> >> >> > >
