On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <mich...@michaelbrooks.ca>wrote:
> 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? > This project is my first time using git / github, so I don't have much to draw from. I was going off of others' suggestions on this thread when I proposed the names. > - 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. > Hmm, good point. The goal is to get people downloading Cordova for use to end up with Stable, and for developers to send pull requests against dev. With a forced default branch, I don't think we can accomplish this. > > - Why is the "stable" branch not just "master"? > My thinking was that it's not obvious whether Master == bleeding edge, or Master == Stable version. Using the names "dev" and "stable" makes it a bit clear. So... If github forces us to have a default branch, I'm thinking that having users send pull requests against "dev" is more valuable than having people download the latest "stable" by default. If people are pulling code from github rather than from our release .zip files, then it's likely they want to hack on it anyways, or that they want the dev version to see if bugs are fixed. Soo.... Here's version #3! If anyone can think of how to keep the three branches while addressing being forced to have a default branch, feel free to speak up! :) Cordova repositories have two main branches: 1. master 2. next Topic branches exist for collaborating on features, or for code-review purposes. Cordova uses tags to label releases. - Each release candidate has a tag. e.g. "2.2.0rc1" - Each release has a tag. e.g. "2.2.0" - The "latest" tag points to the last stable release (this follows npm conventions) 1. The "next" branch. - This branch is used only when in the process of doing a release. - All tags are created from this branch. - All release-candidate bug-fixes are done on this branch. 2. The "master" branch. - When not in the release-process, all commits are made here - When in the release-process, all non-bugfix commits are made here - This is where topic-branches are merged into. Cutting a release: 1. git checkout next && git merge --ff-only master 2. Test test test! 3. Fix bugs by committing them directly to "next" and then doing a non-ff merge of next into master 4. Tag release candidate 5. Repeat steps 2-4 as necessary 6. Tag the release (both by version and by updating the "latest" tag) 7. Create distribution .zip file 8. Test one last time using the dist files > > 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 > > >>> > > >> > > >>> > > >> > > >>> > > > > > >>> > > > > >>> > > > >>> > > > > > >
