So there is also http://wiki.apache.org/cordova/CuttingReleases which may be useful (esp Taggin section).
As far as the confusion with the two branch names: "topic_branch" is your local working branch for a bugfix/feature, and "to_be_merged" is really "temporary_new_name_for_a_branch_to_do_rebase_in". I usually skip that step and take the risk or rebasing in topic_branch (aside: this may negatively affect diffs if you push updates for a review-edit-re-review cycle -- but this isn't an issue for cordova). Do not checkout 'next' into your master branch. Update your local branches to include the remote next branch (with 'git pull apache' with no branch) then you can switch to the next branch locally, apply your patch there, and push to that remote branch directly. Later, merge that commit into master locally, and push that. Do not push to apache next from your local master, or else you will push all the changes. I agree, this is a little confusing, but after a few practice runs it should be easy to figure out. You should probably also check what would be pushed with 'git diff apache/[target-branch]' or tag on --stat to that to just see that files that would signal a quick "uh-oh". I'll work to update the wiki later today, and likely others will have more tips on how to make sure we don't make mistakes. -Michal On Wed, Feb 20, 2013 at 12:42 PM, Becky Gibson <gibson.be...@gmail.com>wrote: > 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 > > >> > > >> > > > > >
