On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson <bra...@chromium.org>wrote:
> The founding goal we're trying to accomplish here is that we don't want > everyone sitting on changes to be in the next version while we use master > to prep a release. > > I don't think having one branch for prepping the release and another for > main development is a lot of bureaucracy. > It is not, the 'branch must be named x' is mainly where I have concerns. Really I just want things simple. > > > On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen <purplecabb...@gmail.com > >wrote: > > > I have been quietly listening on this thread, but thought I should at > > least share my opinion. > > > > I don't think adding contribution rules helps anyone. Git is > > complicated enough as it is, and this just all seems like bureaucracy. > > > > I think master should always contain the latest stable code, and be > > periodically tagged with rc's and versions. > > All work should be done in personal forks and feature branches. > > If the latest tag of master is an rc, then we should only be merging > > bugfixes, until the release. > > Immediately after tagging a version we decide which feature branches > > and pull requests to pull in, and go for it. > > > > I don't think this is much different from what we have, but I think > > that is good. > > The suggestions thus far, while interesting, don't increase our > > velocity in my opinion. Also, I can also pretty much guaranty I'll > > screw it up for the next 3-4 versions. ( because I'm dumb ) > > > > Cheers, > > Jesse > > > > > > > > On 2013-01-24, at 5:53 AM, Andrew Grieve <agri...@chromium.org> wrote: > > > > 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 > > > > > > -- @purplecabbage risingj.com
