Re: [DISCUSS] git branching model

I wrote up a quick guide for reviewers to apply the patches to multiple support branches on the wiki [1]. [1] https://cwiki.apache.org/confluence/display/NIFI/Contributor+Guide#ContributorGuide-Stepstomerge/closepullrequestswithtwomainbranches

Re: [DISCUSS] git branching model

On Mon, Apr 4, 2016 at 4:40 PM, Adam Lamar wrote: > On Mon, Apr 4, 2016 at 11:14 AM, Sean Busbey wrote: >> You're correct, a github PR only targets a single branch and Travis-CI >> only checks how the PR does at its own commit hash (that is, it >> doesn't even check what the target branch would l

Re: [DISCUSS] git branching model

On Mon, Apr 4, 2016 at 1:39 PM, Tony Kurc wrote: > Sean, how about yetus? Is this something yetus can do with the patch > testing in an automated way? Right now Yetus only checks a single target branch. For commits that can apply/merge cleanly we could add something to check multiple branches. I

Re: [DISCUSS] git branching model

On Mon, Apr 4, 2016 at 11:14 AM, Sean Busbey wrote: > You're correct, a github PR only targets a single branch and Travis-CI > only checks how the PR does at its own commit hash (that is, it > doesn't even check what the target branch would look like post-merge). > Hey Sean, it looks like Travis-

Re: [DISCUSS] git branching model

Sean, how about yetus? Is this something yetus can do with the patch testing in an automated way? On Apr 4, 2016 1:14 PM, "Sean Busbey" wrote: > You're correct, a github PR only targets a single branch and Travis-CI > only checks how the PR does at its own commit hash (that is, it > doesn't even

Re: [DISCUSS] git branching model

You're correct, a github PR only targets a single branch and Travis-CI only checks how the PR does at its own commit hash (that is, it doesn't even check what the target branch would look like post-merge). On Mon, Apr 4, 2016 at 12:05 PM, Matt Gilman wrote: > To my knowledge, when you open a PR i

Re: [DISCUSS] git branching model

To my knowledge, when you open a PR in GitHub it only allows the contributor to select a single branch. The reviewer would need to check the compatibility if that contribution needs to be applied to both. Depending on the contribution, a separate PR may be required as the codebases diverge. In prac

Re: [DISCUSS] git branching model

Is travis ci / githib able to give immediate feedback if a PR doesn't merge into both? On Mon, Apr 4, 2016 at 12:33 PM, Matt Gilman wrote: > All, > > I have completed the branching discussed last week. > > - master contains the current 1.x baseline - Future 1.x releases will start > from here >

Re: [DISCUSS] git branching model

All, I have completed the branching discussed last week. - master contains the current 1.x baseline - Future 1.x releases will start from here - 0.x contains the 0.x baseline - Future 0.x releases will start from here Going forward all PRs will need to be merged the either or both branches as ap

Re: [DISCUSS] git branching model

The majority consensus is to have master point to our 1.x baseline going forward. Unless there are any strong objections I will set everything up on Monday (4/4) morning. - Create a 0.x branch for all future 0.x releases based on the current state of master. - Apply all 1.x commits from the tempor

Re: [DISCUSS] git branching model

Matt, I agree that the PRs would need to be merged to both baselines at contribution time. If the contribution applies cleanly the reviewer could certainly handle the commit themselves. However, if additional code changes are required because the baselines have diverged, the contributor would prob

Re: [DISCUSS] git branching model

I think I prefer option 2 considering, what may be the incorrect assumption, that rebasing 1.x on 0.x / pushing into 1.x would be easier. Based on outstanding PRs/Patches in conjunction with release cadence there will be more 0.x releases planned. Until we reached the point where the first 1.x rele

Re: [DISCUSS] git branching model

I like option 1 as well. In the case where a fix is to be put into both branches, will the developer be responsible for issuing 2 PRs / patches, one against each branch? This would help in the case that the PR/patch against 0.x won't merge cleanly into master; however the reviewer(s) would need to

Re: [DISCUSS] git branching model

I too prefer option 1 On Tue, Mar 29, 2016 at 8:21 AM, Brandon DeVries wrote: > I agree with Tony on option 1. I think it makes sense for master to be > the most "advanced" branch. New features will then always be applied to > master, and optionally to other branches for older version support

Re: [DISCUSS] git branching model

I agree with Tony on option 1. I think it makes sense for master to be the most "advanced" branch. New features will then always be applied to master, and optionally to other branches for older version support as applicable / desired. On Tue, Mar 29, 2016 at 10:16 AM Tony Kurc wrote: > I like

Re: [DISCUSS] git branching model

I like option 1 On Mar 29, 2016 10:03 AM, "Matt Gilman" wrote: > Hello, > > With NiFi 0.6.0 officially released and our support strategy defined [1], > I'd like to revisit and propose some options for supporting both a 1.x > branch and 0.x branch concurrently. We need an official place where thes

Re: [DISCUSS] git branching model

Hello, With NiFi 0.6.0 officially released and our support strategy defined [1], I'd like to revisit and propose some options for supporting both a 1.x branch and 0.x branch concurrently. We need an official place where these efforts can be worked, contributed to, and collaborated with the communi

Re: [DISCUSS] git branching model

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

Re: [DISCUSS] git branching model

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 drasticall

Re: [DISCUSS] git branching model

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 bat

Re: [DISCUSS] git branching model

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 appl

Re: [DISCUSS] git branching model

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 increment

Re: [DISCUSS] git branching model

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 releas

Re: [DISCUSS] git branching model

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 s

Re: [DISCUSS] git branching model

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 propo

Re: [DISCUSS] git branching model

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 wrote: > While I like gi

Re: [DISCUSS] git branching model

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

Re: [DISCUSS] git branching model

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 wrote: > I tried to use the bitbucket gitflow plugin. It worked great, until it > didn't. It would get in

Re: [DISCUSS] git branching model

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

Re: [DISCUSS] git branching model

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 keepi

Re: [DISCUSS] git branching model

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 t

Re: [DISCUSS] git branching model

Mat, I'm not entirely sure that a release branch would have helped. As I mentioned, we sort of used master as the release branch. I just built off of the wrong commit, which could happen even with a release branch. That being said, I think it is a good idea (I think it would have helped with the 0.

Re: [DISCUSS] git branching model

The release branch approach (at least happy path) is IMHO the way to go. I’d just like to address from personal experience those times when commits don’t cherry-pick over. Do we put the onus on the developer to push PRs for the intended branches? In either case I would think the original patch/P

Re: [DISCUSS] git branching model

+1 for a branching model with master as current dev, release branches for release development and fixes, and tags for marking release points. > > ** What will we call our branches?* > -> development (current the master) > -> v0.x-stable > -> v1.x-stable > -> v2.x-stable (v0.x-stable is deleted) > -

Re: [DISCUSS] git branching model

I am not a git specialist but I can share my view as a user: ** What will master look like while we're doing this?* I've noticed depending on the project a master branch can be a stable branch or a development branch and as long the behaviour of the branches is clearly documented, the approach use

Re: [DISCUSS] git branching model

I still am no Git wizard so happy to be largely in listen mode on this topic. My 'assumption' of what we'd do here is basically as Matt mentions. On Sat, Feb 13, 2016 at 12:35 PM, Matt Gilman wrote: > A couple thoughts... > > Push release branches. This would help avoid the confusion we had wit

Re: [DISCUSS] git branching model

A couple thoughts... Push release branches. This would help avoid the confusion we had with the 0.5.0 release. It would be clear that bug fixes being made for the current release would need to be pushed to both master and the release branch. It would also allow master to continue receiving commits

[DISCUSS] git branching model

All, I wanted to renew a discussion about our git branching model. We posted a proposed roadmap a while back [1]. For those familiar, there are some pretty big features that are going to be awesome, but at the same time, may make having an overlap of supported major versions likely more desirable d