Braden, you're right. I've now done some local playing around in git, and have an updated proposal that uses merges instead of deleting branches. PTAL:
Cordova repositories have three main branches: 1. stable 2. next 3. dev Topic branches also exist for collaborating on features, or for code-review purposes. There is *no* master branch, so that community-driven pull requests will be forced to think about which branch to request against. 1. The "stable" branch. - Sits at the latest stable release of cordova - This changes only when doing fast-forward merges from "next" 2. The "next" branch. - This branch is used only when in the process of doing a release. - All tags (both stable and RC) are done on this branch. - All release-candidate bug-fixes are done on this branch. 3. The "dev" branch. - This is where non-release-candidate commits are done - This is where topic-branches are merged into. Cutting a release: 1. git checkout next && git merge --ff-only dev 2. Test test test! 3. Fix bugs by committing them directly to "next" and then doing a non-ff merge of next into dev 4. Tag release candidate 5. Repeat steps 2-4 as necessary 6. Tag the release 7. Create distribution .zip file 8. Test one last time using the dist files 9. git checkout stable && git merge --ff-only next On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson <bra...@chromium.org>wrote: > I think deleting and recreating branches with the same name can cause > badness in git[1] because of remotes. It's not really the same branch in > terms of commits, and git thinks that your old stable and the new stable > differ by all of each of their commits. Tags can be moved arbitrarily, so I > think stable makes sense as a tag. I'm not sure about how best to handle > next. > > [1] > http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branch > > > On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <agri...@chromium.org > >wrote: > > > Michal's attending hackathons for the week, and I'm not sure we need to > do > > a hang-out for this, as I think we really are quite close to resolving > > this. I'd really like to resolve this ASAP so that we don't need to have > a > > code-freeze for this release. > > > > Here's a proposal: > > > > Cordova repositories have three main branches: > > 1. stable > > 2. next > > 3. dev > > > > Topic branches also exist for collaborating on features, or for > code-review > > purposes. > > > > There is *no* master branch, so that community-driven pull requests will > be > > forced to think about which branch to request against. > > > > 1. The "stable" branch. > > - Sits at the latest stable release of cordova > > - No one ever commits to the "stable" branch. It exists only as a > > short-cut for checking out the latest stable tag. > > > > 2. The "next" branch. > > - This branch exists only when in the process of doing a release. > > - All tags (both stable and RC) are done on this branch. > > - When a stable tag is done: > > - The existing "stable" branch is deleted > > - A new "stable" branch is created from "next". > > - The "next" branch is deleted. > > > > 3. The "dev" branch. > > - This is where all commits are done > > - This is where topic-branches are merged into. > > > > Cutting a release: > > 1. Create "next" from the HEAD of "dev" > > 2. Test test test! > > 3. Fix bugs by committing them to "dev" and then cherry-picking them into > > "next" > > 4. Tag release candidate > > 5. Repeat steps 2-4 as necessary > > 6. Tag the release > > 7. Create distribution .zip file > > 8. Test one last time using the dist files > > 9. Delete "stable" > > 10. Create a new "stable" by branching from the HEAD of "next" > > 11. Delete the "next" branch > > > > > > > > On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <mmo...@chromium.org> > > wrote: > > > > > Just going to throw out one of my personal requirements for whatever > > > proposal we come up with, so it doesn't get lost: > > > > > > * Feature branches are great for feature work and/or large sweeping > > > changes, as are JIRA bugs for tracking them, but cordova has many many > > > trivial issues that could be fixed with "drive-by" patches that require > > as > > > little friction to commit as possible. > > > > > > > > > On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <cmarc...@gmail.com> > > wrote: > > > > > > > How about if there is a specific straw man proposal at the beginning > of > > > > the face-time? Then the folks that are in agreement won't need to say > > > > anything ;-) > > > > > > > > Seriously, making adjustments to something tangible is easier than > > > > instantiating it from scratch. A volunteer for a very simple writeup > on > > > the > > > > wiki? > > > > > > > > -- Marcel Kinard > > > > > > > > > > > > On 1/14/2013 10:06 PM, Michal Mocny wrote: > > > > > > > >> Okay gentlemen, I think there have been countless good points made > > from > > > >> all > > > >> parties, but also some bike-shedding. > > > >> > > > >> Perhaps it is time to schedule some face-time to better articulate > > some > > > of > > > >> the finer points, and to help come to some consensus? > > > >> > > > >> -Michal > > > >> > > > >> > > > > > > > > > >
