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