I'm just a follower of this thread and i don't pretend to having understood everything but i dont' really get how having backward commits from dev to previous release branch could be handled from a dev point of view. How can you automatically backport a simple fix that is using a particular C++ standard feature allowed on dev and not on previous branches? With forward merges this causes dev to have an "old" standard but still feasible. Same for a fix that depends on changes on dev not cherry picked to previous branches. With forward merges when you commit on a "old" branch you suppose that the forward merges will just succeed given that your parent commits should be also on forward branches.
F. Il giorno ven 6 dic 2019 alle ore 11:18 Volker Hilsheimer < volker.hilshei...@qt.io> ha scritto: > > On 27 Nov 2019, at 11:57, Edward Welbourne <edward.welbou...@qt.io> > wrote: > > > > Volker Hilsheimer (26 November 2019 15:42) wrote: > > [snip] > >> If I understood and remember the discussion, then the proposed flow > >> would be: > >> > >> * we make changes to e.g changes-5.12.7 in the 5.12 branch > >> * once 5.12.7 is released, release team copies the file into dev, and > >> makes a separate commit > >> * that commit gets cherry-picked from dev down into 5.15 and 5.14 > >> using the standard process > >> > >> The rationale is that we have only a single such "forward-porting" > >> commit for each release, and to the largest extend follow the standard > >> process. The disadvantage is that the changes-5.12.7 file in dev will > >> have a different history than the same file in 5.12. > >> > >> If I understand your proposal, the process would be: > >> * changes files are updated directly in the release branch, e.g. 5.12 > >> (assuming that 5.12.7 is only for the release team anyway) > >> * we cherry-pick each commit from there forward through 5.14, 5.15, dev > >> > >> The advantage here is that we can track each commit, and have the same > >> history for those files. The disadvantage is that it’s a bigger > >> departure from standard process, with more room for error and > >> overhead. > > > > Alternative proposal (possibly just a restatement): > > * Fresh commits are normally only allowed on dev, with an exception for > > changes files and last-minute hot-fixes on release branches. > > * Every commit has a Pick-to: footer (or whatever name we chose) > > that lists where it's to be cherry-picked to. > > * When a commit merges and isn't itself a cherry-pick, it gets > > cherry-picked to every branch named on its footer. > > > > Then we don't handle forward-picks any differently than backward-picks, > > aside from only allowing the former in rare cases; and we don't handle > > hot-fixes any differently than change files. Simple rules are easy to > follow. > > > > Eddy. > > > > Updating the JIRA ticket with this concise summary from Eddy, we can start > implementing the tooling support based on this flow. > > How we roll this out (phased rollout to avoid “big bang”, or “all in” to > have a homogenous workflow) we can decide when we get there. > > Cheers, > Volker > > _______________________________________________ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > -- Filippo Cucchetto
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development