Can someone please provide a "git cordova release process for dummies" example to make sure I do the release commits and merges properly (the committerWorkflow example didn't help me as I didn't understand the topic_branch and to_be_merged distinction)
At any rate, can I do a git checkout apache next into my "master" branch? Then I can checkout my working_branch, rebase master (which contains the next code) checkout master, merge my fix and push apache next. git checkout apache next git checkout working_branch_with_fix git rebase master git checkout master git merge working_branch_with_fix git push apache next and then repeat this for apache master with the possibility of needing to use -ff when I merge. Am I on the right track? humbled by git, -becky On Fri, Feb 8, 2013 at 5:22 PM, Marcel Kinard <cmarc...@gmail.com> wrote: > Nice! Thanks, Andrew! > > -- Marcel Kinard > > On Feb 7, 2013, at 2:59 PM, Andrew Grieve <agri...@chromium.org> wrote: > > > The doc's not up-to-date, but I think we ended on consensus for the code > > version. I've taken a stab at updating the wiki pages: > > > > http://wiki.apache.org/cordova/CordovaAndGit -- Added the idea of > having > > both a master and a next branch > > http://wiki.apache.org/cordova/CommitterWorkflow -- Added Jesse's > version > > of the "which branch - in code" > > http://wiki.apache.org/cordova/CuttingReleases -- Changed tagging > > instructions to refer to the "next" branch > > > > > > On Thu, Feb 7, 2013 at 1:26 PM, Marcel Kinard <cmarc...@gmail.com> > wrote: > > > >> With 2.5 starting, it appears time to poke this thread. > >> > >> - Is the Google doc refreshed with the latest consensus? > >> - If so, should the Google doc be transferred to a wiki page? > >> - Have the necessary branches been created? > >> - Are we all in the boat, and understand how to row this beast? > >> > >> -- Marcel Kinard > >> > >> On Jan 24, 2013, at 5:14 PM, Jesse <purplecabb...@gmail.com> wrote: > >> > >>> Nice Shaz, but I was hoping it was a github style network visualization > >>> that included a few versions worth of merges. > >>> Who wants to draw that? > >>> > >>> On Thu, Jan 24, 2013 at 2:05 PM, Shazron <shaz...@gmail.com> wrote: > >>> > >>>> Inline image got mangled, here it is linked: http://cl.ly/MOrD > >>>> > >>>> > >>>> On Thu, Jan 24, 2013 at 1:39 PM, Shazron <shaz...@gmail.com> wrote: > >>>> > >>>>> Thanks for the pseudocode Andrew, seems simpler to understand ;) > >> Jesse's > >>>>> re-factor makes it even easier. Here's my contrib for those more > >> visually > >>>>> inclined: > >>>>> > >>>>> > >>>>> [image: Inline image 2] > >>>>> > >>>>> > >>>>> On Thu, Jan 24, 2013 at 1:29 PM, Andrew Grieve <agri...@chromium.org > >>> wrote: > >>>>> > >>>>>> Nice! even simpler. :) > >>>>>> > >>>>>> > >>>>>> On Thu, Jan 24, 2013 at 3:44 PM, Jesse <purplecabb...@gmail.com> > >> wrote: > >>>>>> > >>>>>>> Thanks for clarifying Andrew. et al, I guess I was > mis-understanding > >>>>>> some > >>>>>>> of the earlier discussion around naming stuff. > >>>>>>> > >>>>>>> So everything is going to master all the time, and we only care > about > >>>>>>> 'next' if we are inReleaseMode and it is a bug fix? > >>>>>>> > >>>>>>> if(inReleaseMode && isBugFix) { > >>>>>>> commitToBranch('next'); > >>>>>>> mergeBranch('next').into('master'); > >>>>>>> } > >>>>>>> else { > >>>>>>> commitToBranch('master'); > >>>>>>> } > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, Jan 24, 2013 at 12:29 PM, Andrew Grieve < > >> agri...@chromium.org > >>>>>>>> wrote: > >>>>>>> > >>>>>>>> Just to clarify - there should be *no* using of the git > >>>>>> cherry-picking > >>>>>>>> command, only git merge. > >>>>>>>> > >>>>>>>> Jesse - not sure what you're referring to with "branch must be > named > >>>>>> x". > >>>>>>>> The latest revision of the proposal has only two branches: master > >> and > >>>>>>> next. > >>>>>>>> Do you mean you don't like the name "next"? > >>>>>>>> > >>>>>>>> Maybe the proposal will seem simpler if put in the form of code :) > >>>>>>>> > >>>>>>>> if (!inReleaseMode) { > >>>>>>>> commitToBranch('master'); > >>>>>>>> } else { > >>>>>>>> if (isBugFix) { > >>>>>>>> commitToBranch('next'); > >>>>>>>> mergeBranch('next').into('master'); > >>>>>>>> } else { > >>>>>>>> commitToBranch('master'); > >>>>>>>> } > >>>>>>>> } > >>>>>>>> > >>>>>>>> > >>>>>>>> On Thu, Jan 24, 2013 at 3:06 PM, Braden Shepherdson < > >>>>>> bra...@chromium.org > >>>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Most of the time the flow will be unchanged: push to master. > >>>>>> Tagging > >>>>>>>> things > >>>>>>>>> we already know how to do; that doesn't change. > >>>>>>>>> > >>>>>>>>> The only new flow for most people is cherrypicking bug fixes from > >>>>>>> master > >>>>>>>> to > >>>>>>>>> next, which we can give examples of. Plus that could remain the > >>>>>>>>> responsibility of the main platform maintainers, who are doing > the > >>>>>>>> tagging. > >>>>>>>>> > >>>>>>>>> Braden > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Thu, Jan 24, 2013 at 2:56 PM, Jesse <purplecabb...@gmail.com> > >>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> 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 > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> @purplecabbage > >>>>>>> risingj.com > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >>> -- > >>> @purplecabbage > >>> risingj.com > >> > >> > >
