I think we all agree on the general flow of feature branch -> "staging" -> merge into "master" + tag.
Ripple uses "next" as the label for the branch with all stuff going into the next release. I like this approach. On 1/11/13 7:48 AM, "Andrew Grieve" <agri...@chromium.org> wrote: >I don't think there's any advantage to creating them ahead of time, so we >might as well not bother. > > >On Fri, Jan 11, 2013 at 10:32 AM, Braden Shepherdson ><bra...@chromium.org>wrote: > >> Maybe I'm being coloured by the Chrome channels, but it seems to me >>that we >> would be doing our "development" of the next release in "dev", rather >>than >> unstable, and that bleeding edge Cordova users wanting the latest >>features >> with no outright breakages but with higher possibility of bugs should >>use >> "unstable". But I'm not sure how and when changes would move from one to >> the other, whichever way around the names go. I'm imagining the flow >>would >> be: >> Feature branches ---ready to push--> my "dev" (your "unstable") >> ---release candidate--> my "unstable" (your "dev") ---release--> >> stable, tagged. >> >> Are we going to have branches for each minor release (ie. 2.3, 2.4) so >>that >> we can do point releases on them? Or would those be created only as >> necessary when we needed a point release? >> >> >> On Thu, Jan 10, 2013 at 9:05 PM, Andrew Grieve <agri...@chromium.org> >> wrote: >> >> > I'm not clear on the difference between dev and unstable. If >>something is >> > so shaky that we're considering not putting it in the next release, >>then >> > I'd think that would go on a named feature branch (e.g. >>array_buffers). >> > >> > Unless... is the purpose of dev to be where we put together a release >> > candidate? If so, maybe a better name would be "staging" >> > >> > >> > On Thu, Jan 10, 2013 at 8:13 PM, Filip Maj <f...@adobe.com> wrote: >> > >> > > On 1/10/13 5:07 PM, "Brian LeRoux" <b...@brian.io> wrote: >> > > >> > > >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. >> > > >> > > ^^ merged from master? >> > > >> > > >- 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? >> > > >> > > >> > >>
