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