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 <[email protected]> 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 <[email protected]> > 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 <[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 > > >>> > > > >>> > > >> > > >>>>>>>>>>>>> > > >>> > > >> > > >>>>>>>>>> > > >>> > > >> > > >>>>>>> > > >>> > > >> > > >>>>> > > >>> > > >> > > >>> > > >>> > > >> > > >>> > > >>> > > >> > > >> > > >>> > > >> > > > > >>> > > >> > > > > >>> > > >> > > > >>> > > >> > > >>> > > > > >>> > > > >>> > > >> > > >> > > > > > >
