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 >
