It sounds like you have a very good idea of how to solve our problems! I suggest you run with it! :D As you mention, probably best to spin this out to another thread. (Or tac it on to the end of the existing "[DISCUSS] Git workflow" thread. We really need to drive that to conclusion as soon as possible.) Ideally, once we've agreed on what we want to do here, someone moves it to the wiki, and we let it mature there for a while, before moving to the docs.
Randall, can you also help me prepare the commands / instructions to send out at the various points during the release cycle? I'd like to have copy-and-paste-able things people can use to help them get things sorted. On 22 May 2013 02:29, Randall Leeds <[email protected]> wrote: > On Tue, May 21, 2013 at 6:22 PM, Randall Leeds <[email protected]> > wrote: > > Here's a diagram. In this I show a feature branch landing on master > > and a backport of it landing on 1.3.x, but if we follow the procedure > > I'm suggesting I think it can even be easy to keep track of > > cherry-picked backports. > > > > https://friendpaste.com/2AW98kyY8gQck6W1CjpZLY > > > > The fancy things here are > > * merge-base: to find the common ancestor > > * --no-commit: so NEWS and CHANGES can be reconciled atomically with > > respect to what the git logs will say is unmerged > > * -Xours: so that we can merge release branches to master *without* > > code changes, just to mark a point in history so that a future > > merge-base will only show us what hasn't made it into NEWS and CHANGES > > since we last did this. > > This last one is the key piece. By using the "ours" merge strategy we > can mark at point in history where the *history* is said to be > reconciled (we've updated NEWS and CHANGES in both merge parents) > without accidentally forward-porting code changes. We can record new > merge bases for the release branches vis-a-vis master, which makes > reading the logs for NEWS and CHANGES maintenance easier, and at the > same time we record the current state of NEWS and CHANGES. > > But maybe I'm overthinking it since one alternative is to just update > NEWS and CHANGES whenever we make commits. However, I think if we just > merge releases to master whenever we make a backport or a release then > it will be a very quick and painless process to update NEWS and > CHANGES when it comes time for 1.4.x. > -- NS
