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