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 > >
