nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Gilman <matt.c.gil...@gmail.com>
Subject Re: [DISCUSS] git branching model
Date Mon, 04 Apr 2016 16:33:49 GMT
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.gilman@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.gilman@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 <aldrinpiri@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 <mattyb149@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.witt@gmail.com> wrote:
>>> >
>>> > > I too prefer option 1
>>> > >
>>> > > On Tue, Mar 29, 2016 at 8:21 AM, Brandon DeVries <brd@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 <trkurc@gmail.com>
>>> wrote:
>>> > > >
>>> > > >> I like option 1
>>> > > >> On Mar 29, 2016 10:03 AM, "Matt Gilman" <matt.c.gilman@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.miskin@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 <aldrinpiri@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 <
>>> trkurc@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.miskin@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 <jvwing@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.witt@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 <
>>> > jvwing@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.witt@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.witt@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 <
>>> > > trkurc@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 <
>>> > > >> > > >>>>>>> bimargulies@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
>>> > > >> > > >>>>>>>>>> <bimargulies@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 <
>>> > > >> > adam@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 <
>>> > > >> > > >>>>> thadguidry@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
>>> >
>>> > > >> > > >>>>>>>>>>>>>
>>> > > >> > > >>>>>>>>>>
>>> > > >> > > >>>>>>>
>>> > > >> > > >>>>>
>>> > > >> > > >>>
>>> > > >> > > >>>
>>> > > >> > > >>
>>> > > >> > >
>>> > > >> > >
>>> > > >> >
>>> > > >>
>>> > >
>>> >
>>>
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message