I guess it will depend how much change is expected on the maintenance branches, but if you want every change in the maintenance branch to go into the main-line branch then there is little difference from a conflict point of view between a series of cherry-picks and a merge.
Either way, it is just another approach to consider. There’s more than one way to do it, and I suspect there isn’t any solution that makes it trivial. Cheers, Richard > On 27 Feb 2016, at 14:43, Aldrin Piri <[email protected]> wrote: > > On board with Tony's points. I think the realities of merging in practice > when that "breaking point" of sorts occurs will make the complexity and > overhead quite difficult and maybe even more error prone than the cherry > picking approach with some additional guidelines. When the codebase > drastically changes, the merge conflicts could be quite severe and without > a good knowledge of each part of the codebase involved during that process, > a committer may introduce regressions. > > On Sat, Feb 27, 2016 at 7:58 AM, Tony Kurc <[email protected]> wrote: > >> the reason I like applying patches to both lines is that once code begins >> to diverge, cleanly merging into one codebase can be impossible. having >> good practices for managing patches and where they apply is paramount for >> success. >> >> I expect that divergence to happen with 1.x. I wanted to get in a battle >> rhythm of sorts of managing multiple lines, even if the patches COULD be >> applied to both in the manner you described. >> >> Joe W and I did a wee bit of scrambling to ensure that tickets marked for >> 0.5.1 had the right patches in the support branch, and some didn't, so I >> think "lesson learned". I do like in the apache infrastructure that if >> commits have the appropriate ticket in their commit message, the jira will >> have the list of commits and branches those commits were applies to. >> However, I think we may need to revisit commit message "hygiene" if we >> relied on this instead of more manual review. >> >> >> >> >> >> On Sat, Feb 27, 2016 at 4:45 AM, Richard Miskin <[email protected]> >> wrote: >> >>> Hi, >>> >>> On a couple of work projects we found that the approach of cherry-picking >>> commits can lead to an unnecessarily complicated history where the same >>> piece of work appears as multiple separate commits on different branches. >>> This can then make it hard to be confident that a bug fix has been >> applied >>> to all relevant branches. We found that it works better to aim to commit >>> changes to the lowest applicable branch, and then regularly merge those >>> branches to master. This approach is based on the git-flow model ( >>> http://nvie.com/posts/a-successful-git-branching-model/ < >>> http://nvie.com/posts/a-successful-git-branching-model/>). >>> >>> Looking at the repo there are already a few commits that are duplicated >> on >>> master and 0.5.1. Using the model I suggest they’d only occur on 0.5.1, >> and >>> then that branch would get merged to master. >>> >>> Having the merge commits from the support branch to master makes it >>> explicit in the git history that all bug fixes (and associated tests) >> have >>> been pulled through to master. >>> >>> Cheers, >>> Richard >>> >>>> On 26 Feb 2016, at 06:59, James Wing <[email protected]> wrote: >>>> >>>> Thanks, Joe, let me try rephrasing a few of those and see if you agree: >>>> >>>> 1.) Commits merged to master today are destined for the next minor >>> release, >>>> currently 0.6.0, by default? >>>> >>>> By default, commits to master will be released in the next major or >> minor >>>> release. No commits are included in incremental/patch releases by >>> default. >>>> >>>> >>>> 3.) How long will support/0.5.x be maintained? >>>> >>>> support/0.5.x will be maintained until the first of the following >> events: >>>> a.) 0.6.0 is released (next minor release in major release line) >>>> b.) One year after 1.0.0 is released ("previous major release lines up >> to >>>> one year since the last minor release (0.4.y, 1.5.y) in that line") >>>> >>>> But additional support might be available by special request. >>>> >>>> >>>> 4.) Where is compatibility-breaking code destined for a future major >>>> release stored? Is it visible anywhere? >>>> >>>> I suppose Jira tickets targeting the next major release >>> could/should/would >>>> (do?) push branches. That seems weak in the face of a probable >> stampede >>>> towards the fire exit of a major release, but it's a start. I'm not >>> aware >>>> of any great solutions here, certainly not for an open-source project. >>>> >>>> >>>> On Thu, Feb 25, 2016 at 4:56 PM, Joe Witt <[email protected]> wrote: >>>> >>>>> James, >>>>> >>>>> These are great questions to frame and test the model. So let's >>>>> attempt to address them agains the model. >>>>> >>>>> Here is the language for that model at this time: >>>>> >>>>> - We support the newest major release line (0.x, 1.x) and any previous >>>>> major release lines up to one year since the last minor release >>>>> (0.4.y, 1.5.y) in that line >>>>> >>>>> - When master has no releases we will backport any appropriate changes >>>>> (fix, feature, enhancement) to the previous major release line >>>>> >>>>> - Any security or data loss related fixes should be back ported to all >>>>> supported major release lines >>>>> >>>>> - Fixes, improvements, features will be applied to the next release >>>>> (minor or incremental) within a given major release line and will only >>>>> be back ported on a case by case basis for fixes >>>>> >>>>> - In order to consider a patch for back porting to a previous minor >>>>> release line a request needs to be made to the developer or user >>>>> mailing list with a successful discussion and a release candidate >>>>> produced' >>>>> >>>>> So with those above let's review 1 through 5 in turn. >>>>> >>>>> 1.) Commits merged to master today are destined for the next minor >>>>> release, currently 0.6.0, by default? >>>>> >>>>> Master is for whatever is the most leading edge release line working >>>>> toward the next release. At the time that a minor release occurs >>>>> against that release line then it branches off into a support/x.y.* >>>>> branch for any further efforts against it. >>>>> >>>>> 2.) Is master always open for merging new code, or are there >>> restrictions >>>>> before or after releases? >>>>> >>>>> I believe master would be always open for new code. From some point >>>>> at which a release is considered feature complete then further feature >>>>> enhancements need to go on master as part of the next release effort. >>>>> >>>>> 3.) How long will support/0.5.x be maintained? >>>>> >>>>> The most recent minor release line of a major line will be supported >>>>> for up to one year from whenever it was released where support is for >>>>> bug fixes for security or data loss related items. Releases for older >>>>> minor lines should be considered on a case by case basis and if >>>>> requested. Otherwise the basic premise is the train is moving >>>>> forward. >>>>> >>>>> 4.) Where is compatibility-breaking code destined for a future major >>>>> release stored? Is it visible anywhere? >>>>> >>>>> It must be visible. It should be placed into a branch until such >>>>> time that it is ready to become the new master. That time would be >>>>> when the next release will be for that line. When I think about this >>>>> against the stated model we could probably tweak the wording to better >>>>> articulate that. I think it was what was meant with 'when master has >>>>> no releases we will backport...' but that is unclear. >>>>> >>>>> 5.) A critical data/security bug found after 1.0 would eligible to be >>>>> backported only to the last minor release in the 0.x line, or to all >>> minor >>>>> releases in the 0.x line? >>>>> >>>>> Only to the most recent minor release of any still supported major >>>>> line. However, the catch of 'case by case' determination for older >>>>> minor lines is still in play. Basically if someone requests it and >>>>> can get enough momentum for it then it should be no problem to produce >>>>> such a release. >>>>> >>>>> Thanks >>>>> Joe >>>>> >>>>> On Thu, Feb 25, 2016 at 3:15 PM, James Wing <[email protected]> wrote: >>>>>> I have some rhetorical questions for discussion of the branching >> model: >>>>>> >>>>>> 1.) Commits merged to master today are destined for the next minor >>>>> release, >>>>>> currently 0.6.0, by default? >>>>>> >>>>>> 2.) Is master always open for merging new code, or are there >>> restrictions >>>>>> before or after releases? >>>>>> >>>>>> 3.) How long will support/0.5.x be maintained? >>>>>> >>>>>> 4.) Where is compatibility-breaking code destined for a future major >>>>>> release stored? Is it visible anywhere? >>>>>> >>>>>> 5.) A critical data/security bug found after 1.0 would eligible to be >>>>>> backported only to the last minor release in the 0.x line, or to all >>>>> minor >>>>>> releases in the 0.x line? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Feb 25, 2016 at 8:01 AM, Joe Witt <[email protected]> >> wrote: >>>>>> >>>>>>> Given the discussion has stalled i'd like to turn it more toward a >>>>>>> proposal as we're at a point now where we need to start executing >> some >>>>>>> of these approaches. We're actually already seeing it take form in >>>>>>> the support/0.5.x branch and the master branch (which is for 0.6.0 >> at >>>>>>> this point). >>>>>>> >>>>>>> The proposal then for Git processes based on the other thread [1] >>>>>>> where we outline a support model: >>>>>>> >>>>>>> - We will have a branch for each major release line >>>>>>> >>>>>>> - The branch designated 'master' will be for the latest major >> release >>>>>>> line under active development >>>>>>> >>>>>>> - Commits against master should be evaluated for whether they should >>>>>>> be cherry-picked to other still supported major release lines >>>>>>> consistent with the community support model >>>>>>> >>>>>>> - When a release occurs a signed tag will be generated and the >> version >>>>>>> for that major line will be bumped to the next incremental release >>>>>>> snapshot >>>>>>> >>>>>>> - The next commit on a given major release line that requires a >> minor >>>>>>> version change should increment the minor version number and reset >>>>>>> incremental to zero >>>>>>> >>>>>>> - Major version changes should only ever be prompted from the master >>>>>>> branch and should only occur when a commit warrants changing the >> major >>>>>>> version at which point a major release line branch should be created >>>>>>> off of master for the previous major release line >>>>>>> >>>>>>> [1] >>>>>>> >>>>> >>> >> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E >>>>>>> >>>>>>> Thanks >>>>>>> Joe >>>>>>> >>>>>>> On Tue, Feb 16, 2016 at 3:13 PM, Joe Witt <[email protected]> >> wrote: >>>>>>>> I don't want to kill this thread. It is good to discuss specific >>>>>>>> tooling/procedures. But I do want to get some consensus discussion >>>>>>>> around Tony's original intent (as I read it). So kicked off a >>>>>>>> discussion back at that level. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc <[email protected]> >> wrote: >>>>>>>>> While I like gitflow, I can't say I like any of the plugins that >> are >>>>>>> used. >>>>>>>>> I have worked on some other projects (unfortunately not open >> source) >>>>>>> that >>>>>>>>> use a gitflow inspired workflow, without ever using a plugin. Nice >>>>> side >>>>>>>>> effect is that I believe this got me better at using git, and >>>>> generally >>>>>>> we >>>>>>>>> all got better at managing merge pain. >>>>>>>>> >>>>>>>>> On merge problems, I think the reason we're operating the way we >> are >>>>>>> now is >>>>>>>>> to avoid merge mayhem. I think the initial bar for a patch is "can >>> be >>>>>>>>> merged into master", and we have our friend Travis to make this >> even >>>>>>> easier >>>>>>>>> to know upfront. This greatly simplifies things. If a bugfix is >>>>> "patch >>>>>>>>> needs to be able to apply onto the current release in progress, >>>>> master, >>>>>>> and >>>>>>>>> several other versions we're supporting, with possibly drastically >>>>>>>>> different code", well then things get interesting. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Feb 15, 2016 at 12:04 PM, Benson Margulies < >>>>>>> [email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> The issue tracker >>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>> >>> >> https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues >>>>>>>>>> might also prove useful in evaluating it. >>>>>>>>>> >>>>>>>>>> On Mon, Feb 15, 2016 at 12:03 PM, Benson Margulies >>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>> I tried to use the bitbucket gitflow plugin. It worked great, >>>>> until >>>>>>> it >>>>>>>>>>> didn't. It would get into terrible, inexplicable, merge >> problems. >>>>> No >>>>>>>>>>> one seemed to be maintaining it. >>>>>>>>>>> >>>>>>>>>>> There's a new offering in this dept: >>>>>>>>>>> https://github.com/egineering-llc/gitflow-helper-maven-plugin. >>>>>>>>>>> >>>>>>>>>>> On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <[email protected]> >>>>>>> wrote: >>>>>>>>>>>> One of the harder things with gitflow is using it in >> combination >>>>>>> with >>>>>>>>>>>> maven. It's ideal that the tags and releases are tracking >>>>> closely >>>>>>> with >>>>>>>>>> the >>>>>>>>>>>> maven pom.xml version. gitflow, on its own, doesn't keep the >> pom >>>>>>>>>> version >>>>>>>>>>>> updated with the git release names. >>>>>>>>>>>> >>>>>>>>>>>> Because of the general importance of keeping releases and tags >>>>>>>>>> synchronized >>>>>>>>>>>> with the pom version, I think whatever we do, it needs to be >>>>>>> approached >>>>>>>>>>>> with tools that are available through maven rather than from >> git. >>>>>>> The >>>>>>>>>>>> git-flow plugin (referenced by Thad) doesn't directly help deal >>>>> with >>>>>>>>>> this >>>>>>>>>>>> synchronization, since it's a git tool, not a maven tool. >>>>>>>>>>>> >>>>>>>>>>>> I've been using, with reasonable success, the jgitflow [1] >>>>> plugin, >>>>>>> which >>>>>>>>>>>> does a reasonable job of following the gitflow model for a >> maven >>>>>>>>>> project. >>>>>>>>>>>> I don't recommend this plugin for NIFI, because it insists that >>>>> the >>>>>>>>>> master >>>>>>>>>>>> branch is strictly used for published release tags (as per the >>>>>>> strict >>>>>>>>>>>> gitflow workflow). I just mention this, in reference to how >> some >>>>>>>>>> plugins >>>>>>>>>>>> are tackling the gitflow and maven synchronization issue. >>>>>>>>>>>> >>>>>>>>>>>> [1] http://jgitflow.bitbucket.org/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry < >>>>> [email protected] >>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Your on the right track / idea with Git-flow. Your Master >>>>> become >>>>>>>>>> primary >>>>>>>>>>>>> development of next release (with feature branches off of >> it).. >>>>>>> while >>>>>>>>>> you >>>>>>>>>>>>> continue to have release branches that can have hot fix >> branches >>>>>>> off of >>>>>>>>>>>>> them. (don't use Master as your release branch ! - bad >>>>> practice ! >>>>>>> ) >>>>>>>>>>>>> >>>>>>>>>>>>> Here is the Git-flow cheat sheet to make it easy for everyone >> to >>>>>>>>>>>>> understand... just scroll it down to gain the understanding. >> Its >>>>>>> really >>>>>>>>>>>>> that easy. >>>>>>>>>>>>> >>>>>>>>>>>>> http://danielkummer.github.io/git-flow-cheatsheet/ >>>>>>>>>>>>> >>>>>>>>>>>>> Most large projects have moved into using git-flow ... and >> tools >>>>>>> like >>>>>>>>>>>>> Eclipse Mars, IntelliJ, Sourcetree, etc...have Git-flow either >>>>>>> built >>>>>>>>>> in or >>>>>>>>>>>>> plugin available now. If you want to live on the command >> line, >>>>>>> then >>>>>>>>>> that >>>>>>>>>>>>> is handled easily by the instructions in the above link. >>>>>>>>>>>>> >>>>>>>>>>>>> Thad >>>>>>>>>>>>> +ThadGuidry <https://www.google.com/+ThadGuidry> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>> >>> >>> >>
