cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: too long to package a release?
Date Wed, 20 Feb 2013 19:55:07 GMT
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 <fil@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" <shazron@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 <fil@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" <agrieve@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 <fil@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" <mmocny@chromium.org>
wrote:
> >> >>>
> >> >>> >oooo I didn't know that.  Thanks!
> >> >>> >
> >> >>> >
> >> >>> >On Wed, Feb 20, 2013 at 1:10 PM, Becky Gibson
> >> >>> ><gibson.becky@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
> >><mmocny@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
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message