Thank you. I lean to agreement w/ Andrew that more meaningful pull reqs are better and having named branches for what they do makes sense. Also agree that tags are for points in time---but I take no exception to a branch for those as well for dev purposes.
Let me try to capture the conversation to this point: Branches: - Master gets deleted. We want meaningful pull requests and this will force folks to pick a branch to dev against. - Stable: This is stable and frozen on the last tagged release. - Dev: The next release to be tagged. Feature branches merged from master when confident. This should build cleanly. - Unstable: the current working branch. Feature branches merged as needed for collaboration. No guarantee it builds. Tags: - Happen on the Stable branch. Workflow - Everyone works from local feature branch rebasing and committing to Unstable as neccessary. - When that feature branch is considered good enough, it is merged into Dev. - On release date whatever is Dev is rebased to Stable. Tagged. Released. Thoughts? On Thu, Jan 10, 2013 at 7:02 AM, Marcel Kinard <cmarc...@gmail.com> wrote: > Poking this thread. So is there consensus on how to do this? If so, can this > be summarized and written up, perhaps on the ContributorWorkflow / > CommiterWorkflow wiki pages? > > And when would we want to start operating with this, 2.4/now or later? > > -- Marcel Kinard
