Before we move forward, I have a few questions about the "no master" approach.
There is *no* master branch, so that community-driven pull requests will be > forced to think about which branch to request against. - Andrew, can you cite other projects that do not use a master branch? - On Github, you must have a default branch. If not master, it must be something else. So, users are not forced to think about the branch to send a pull request again... they will likely just use the default. - Why is the "stable" branch not just "master"? Thanks, Michael On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <b...@brian.io> wrote: > 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 > >>> > > >> > >>> > > >> > >>> > > > > >>> > > > >>> > > >>> > > >
