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