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 appropriate to ensure it's included in subsequent releases. I will be updating the quick start and contributor guide to describe the distinction between the two branches. Thanks! Matt On Thu, Mar 31, 2016 at 4:35 PM, Matt Gilman <[email protected]> wrote: > 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 temporary 1.x branch to master. > - Delete the temporary 1.x branch. > - Update the quickstart page and contribution guide to detail the > distinction between the 0.x and master branches. > - Send another email to @dev once this has been completed. > > Reminder: Going forward once this has been completed all commits will need > to be made to both branches as appropriate. > > Thanks! > > Matt > > On Tue, Mar 29, 2016 at 3:05 PM, Matt Gilman <[email protected]> > wrote: > >> 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 >> probably need to submit another PR. This additional effort should only be >> necessary until we're able to perform the first 1.x release. >> >> Aldrin, >> >> I definitely understand your thoughts regarding (1) and (2). This is why >> I wanted to pose the options before just jumping into one approach vs the >> other. I personally prefer the GitHub style PR process. I realize this is >> more cumbersome but hopefully the number of conflicts should be small as >> folks are already starting to focus their efforts on the framework for 1.x. >> >> Matt >> >> On Tue, Mar 29, 2016 at 10:55 AM, Aldrin Piri <[email protected]> >> wrote: >> >>> 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 release is in sight, I think (2) makes sense just from >>> minimizing >>> impedance where the majority of effort will occur (new/updated >>> extensions) >>> and then switching to (1) when we are scheduling 1.x as next (exclusive >>> of >>> any patch builds). This seems to work out when I try to reason about it, >>> but admittedly, am coming at this heavily from my own anecdotal >>> perspective >>> given my flow of reviewing. >>> >>> Matt, excellent points to consider. >>> >>> Do not want to go too much on a tangent from the current conversation, >>> but >>> I think we need to harness automation as much as possible. Not sure >>> Travis >>> can do this or do so easily (short of two PRs) and this may arguably >>> shift >>> things in favor of patches and the model that the other ASF projects >>> utilize with buildbot. Getting as much done asynchronously for us is >>> obviously important but we also have to strive to avoid a contrib process >>> that is too cumbersome as well. >>> >>> On Tue, Mar 29, 2016 at 10:33 AM, Matt Burgess <[email protected]> >>> wrote: >>> >>> > 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 make sure there >>> were no >>> > breaking changes as a result of the manual merge to master. An >>> alternative >>> > is that the reviewer(s) do the forward-port, which I don't think is a >>> good >>> > idea. However the reviewer would need to make sure the PR(s) are >>> against >>> > the correct branch. For example, all current PRs would need to be >>> > "backported" to the new 0.x branch. >>> > >>> > Also, I would think the PRs/patches need to be merged at the same time >>> (or >>> > soon), to avoid regressions (i.e. a bug fix going into 0.x but getting >>> > forgotten/missed for 1.x). >>> > >>> > Thoughts? Thanks, >>> > Matt >>> > >>> > On Tue, Mar 29, 2016 at 10:26 AM, Joe Witt <[email protected]> wrote: >>> > >>> > > I too prefer option 1 >>> > > >>> > > On Tue, Mar 29, 2016 at 8:21 AM, Brandon DeVries <[email protected]> >>> 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 >>> as >>> > > > applicable / desired. >>> > > > >>> > > > On Tue, Mar 29, 2016 at 10:16 AM Tony Kurc <[email protected]> >>> wrote: >>> > > > >>> > > >> 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 >>> > >>> > > >> > > >>>>>>>>>>>>> >>> > > >> > > >>>>>>>>>> >>> > > >> > > >>>>>>> >>> > > >> > > >>>>> >>> > > >> > > >>> >>> > > >> > > >>> >>> > > >> > > >> >>> > > >> > > >>> > > >> > > >>> > > >> > >>> > > >> >>> > > >>> > >>> >> >> >
