Ok so the flow is: if you are committing into next, always merge into master. Good. So the CI setup doesn't need to differentiate between master and next. It can always pull from master.
On 2/20/13 11:04 AM, "Andrew Grieve" <agri...@chromium.org> wrote: >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 >> >> > > > >> >> >> > > > >> >> >> > > > >> >> > > > >> >> > > >> >> > >> >> >> >>
