Right, that makes sense. In our specific case with all projects having a
VERSION file it should be a commit but I understand your point :)

On 2/20/13 11:55 AM, "Michal Mocny" <mmo...@chromium.org> wrote:

>Fil: yes, that graph looks correct, with the added note that your rc/final
>point release "commits" are conceptually just tags.  Its possible those
>also accompany a commit to change some versioning changes in text files,
>I'm not sure, but not necessarily.
>
>-Michal
>
>
>On Wed, Feb 20, 2013 at 2:47 PM, Filip Maj <f...@adobe.com> wrote:
>
>> 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
>> >>
>>
>>

Reply via email to