So when we release a final point release (that is a culmination of rcs,
i.e. 2.5.0rc1->2.5.0rc2->2.5.0), at that point on the next branch
effectively stops being in use.
ASCII graph incoming of potential scenario
Master Branch o--E---o--o--o--o--o--o--o--o
\ / / / \
Next Branch A--B--C--D F
Where:
A = initial rc1 commit (2.5.0rc1)
B = some regression bug fix
C = rc2 commit (2.5.0rc2)
D = final point release (2.5.0)
E = some feature that landed on master during release candidate time
F = rc1 commit for NEXT point release (2.6.0rc1)
Does the above look correct?
So in the end the git flow does not speed up our release time at all, it
just enables split-stream development (which is fine by me).
The reason we are taking long to package a release is because the JS is a
shared dependency across all platforms, and finding regressions in the JS
requires a repackaging across all platforms.
Until we can fully automate the packaging and tagging for platforms, and
testing on devices, we will be stuck with a (relatively speaking) slow
release process.
On 2/20/13 11:34 AM, "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
>>
