Step 5 here: http://wiki.apache.org/cordova/CommitterWorkflow
Probably it should be "isFixingRegression" instead of "isBugFix". I'll update it now. On Wed, Feb 20, 2013 at 1:59 PM, Filip Maj <f...@adobe.com> wrote: > I noticed on iOS the commits going into next are mirrored on master. > > For Android that was not done. > > What is the correct process? > > On 2/20/13 10:12 AM, "Michal Mocny" <mmo...@chromium.org> wrote: > > >oooo I didn't know that. Thanks! > > > > > >On Wed, Feb 20, 2013 at 1:10 PM, Becky Gibson > ><gibson.be...@gmail.com>wrote: > > > >> Thank you, Michael! I do usually go a git push --dry-run to check that > >>I > >> am pushing what I expect but I'll try the diff as well. > >> > >> > >> On Wed, Feb 20, 2013 at 1:07 PM, Michal Mocny <mmo...@chromium.org> > >>wrote: > >> > >> > 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 > >> > > > >> > >> > > > >> > >> > > > > >> > > > > >> > > > >> > > >> > >
