Looks great Andrew! If everyone's on board, how are we going to test run this? Flip a switch at a certain point, give it a shot with one repo for one RC?
On 1/22/13 12:29 PM, "Andrew Grieve" <agri...@chromium.org> wrote: >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-branc >>h >> >> >> 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 >> > > >> >> > > >> >> > > > >> > > >> > >>
