I like option 1 On Mar 29, 2016 10:03 AM, "Matt Gilman" <[email protected]> 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 these > efforts can be worked, contributed to, and collaborated with the community. > I've already created a 1.x branch as a temporary place for this codebase to > live until we agree to an approach. > > Either option I'm proposing will require PRs/contributions/patches to be > applied to both branches as applicable. This means that the contributor or > the reviewer will need to be able to apply the commits in both places if > it's necessary. For instance, framework code has already started diverging > from the current master so any framework change may not need to be applied > to both if the changeset is not applicable to the 1.x baseline. > > The only question at the moment is what master will refer to. > > 1) Create a branch for 0.x and allow master to become the 1.x baseline > going forward. Future 0.x releases will be performed from the 0.x branch. > 2) Continuing working on the 1.x branch as is. Allow master to continue to > servicing 0.x releases. Once a 1.x release is made, create the 0.x branch > and then allow master to service 1.x releases. > > In short, when do we want master to point to the 1.x baseline? When should > we create a branch where 0.x releases will be made from. Regardless, > contributions will need to be performed to both places as applicable. > > Thanks. > > Matt > > [1] > > http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E > > On Sat, Feb 27, 2016 at 10:08 AM, Richard Miskin <[email protected]> > wrote: > > > 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> > > >>>>>>>>>>>>> > > >>>>>>>>>> > > >>>>>>> > > >>>>> > > >>> > > >>> > > >> > > > > >
