I'm liking it. Start in 2.5?
On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <f...@adobe.com> wrote: > 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 >>> > > >> >>> > > >> >>> > > > >>> > > >>> > >>> >
