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 <matt.c.gil...@gmail.com> wrote: > 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 practice though, most of the work on master (1.x) will focus on > the framework which is where diverging is most likely to occur. > Consequently, framework bug fixes are the most likely place where we may > need separate PRs. > > On Mon, Apr 4, 2016 at 12:46 PM, Tony Kurc <trk...@gmail.com> wrote: > >> 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 <matt.c.gil...@gmail.com> >> 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 >> > - 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 <matt.c.gil...@gmail.com> >> > 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 <matt.c.gil...@gmail.com> >> > > 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 <aldrinp...@gmail.com> >> > >> 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 <mattyb...@gmail.com> >> > >>> 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 <joe.w...@gmail.com> >> > wrote: >> > >>> > >> > >>> > > I too prefer option 1 >> > >>> > > >> > >>> > > On Tue, Mar 29, 2016 at 8:21 AM, Brandon DeVries <b...@jhu.edu> >> > >>> 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 <trk...@gmail.com> >> > >>> wrote: >> > >>> > > > >> > >>> > > >> I like option 1 >> > >>> > > >> On Mar 29, 2016 10:03 AM, "Matt Gilman" < >> > matt.c.gil...@gmail.com> >> > >>> > > 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 < >> > >>> > > r.p.mis...@gmail.com> >> > >>> > > >> > 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 < >> > aldrinp...@gmail.com >> > >>> > >> > >>> > > 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 < >> > >>> trk...@gmail.com> >> > >>> > > 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 < >> > >>> > > >> r.p.mis...@gmail.com >> > >>> > > >> > > >> > >>> > > >> > > >> 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 < >> jvw...@gmail.com >> > > >> > >>> > 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 < >> > >>> > joe.w...@gmail.com> >> > >>> > > >> > 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 < >> > >>> > jvw...@gmail.com >> > >>> > > > >> > >>> > > >> > > 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 < >> > >>> > > joe.w...@gmail.com> >> > >>> > > >> > > >> 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 < >> > >>> > > joe.w...@gmail.com> >> > >>> > > >> > > >> 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 < >> > >>> > > trk...@gmail.com> >> > >>> > > >> > > >> 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 < >> > >>> > > >> > > >>>>>>> bimargul...@gmail.com> >> > >>> > > >> > > >>>>>>>>> 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 >> > >>> > > >> > > >>>>>>>>>> <bimargul...@gmail.com> 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 < >> > >>> > > >> > a...@adamtaft.com >> > >>> > > >> > > > >> > >>> > > >> > > >>>>>>> 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 < >> > >>> > > >> > > >>>>> thadgui...@gmail.com >> > >>> > > >> > > >>>>>>>> >> > >>> > > >> > > >>>>>>>>>> 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 >> > >>> > >> > >>> > > >> > > >>>>>>>>>>>>> >> > >>> > > >> > > >>>>>>>>>> >> > >>> > > >> > > >>>>>>> >> > >>> > > >> > > >>>>> >> > >>> > > >> > > >>> >> > >>> > > >> > > >>> >> > >>> > > >> > > >> >> > >>> > > >> > > >> > >>> > > >> > > >> > >>> > > >> > >> > >>> > > >> >> > >>> > > >> > >>> > >> > >>> >> > >> >> > >> >> > > >> > >>
