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 > >> > >
