Shaz sums it up perfect. Once we cut 'next' nothing goes in unless its critical to it being a good release. Anything that goes into next should almost by definition also go in to master.
Note that this is functionally the same as only ever pushing to master, and cherry-picking certain commits into 'next'. -Michal On Wed, Feb 20, 2013 at 2:34 PM, Shazron <shaz...@gmail.com> wrote: > http://cl.ly/MOrD > Master always has all the changes. Next will never have experimental > changes/features after next is created, just bug fixes. > > On Wednesday, February 20, 2013, Joe Bowser wrote: > > > Honestly, this process is too complex and we should just go back to > > what we were doing before. I don't think our git flow was what is > > slowing us down. > > > > > > > > On Wed, Feb 20, 2013 at 11:22 AM, Filip Maj <f...@adobe.com> wrote: > > > 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 > > >
