OK - I've updated the Wiki with this new standard: https://cwiki.apache.org/confluence/display/CURATOR/For+Curator+Committers#ForCuratorCommitters-pr-curator-2.0 <https://cwiki.apache.org/confluence/display/CURATOR/For+Curator+Committers#ForCuratorCommitters-pr-curator-2.0>
I added a note as well to do squash merges. -JZ > On May 9, 2017, at 2:32 AM, Scott Blum <[email protected]> wrote: > > 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] > <mailto:[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] >> <mailto:[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 >> >> >> >> >> >> > >
