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