nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Burgess <mattyb...@gmail.com>
Subject Re: [DISCUSS] git branching model
Date Sun, 14 Feb 2016 02:34:08 GMT
The release branch approach (at least happy path) is IMHO the way to go. I’d just like to
address from personal experience those times when commits don’t cherry-pick over. Do we
put the onus on the developer to push PRs for the intended branches? In either case I would
think the original patch/PR would go against master, then whomever is tasked with getting
it back to the appropriate branches needs to do the cherry-pick (or whatever is the prudent
way to apply the change) and get it into “past” branches. At my last place, the onus was
on the developer to introduce the PR for master and a PR for every previous branch he/she
would like to get the fix/feature into, and approval was given based on branch and community
approval. Working backwards in time like this reduces regressions and forces a per-PR look
at the commit in the appropriate context.

Regards,
Matt



On 2/13/16, 9:26 PM, "Joe Skora" <jskora@gmail.com> wrote:

>+1 for a branching model with master as current dev, release branches for
>release development and fixes, and tags for marking release points.
>>
>> ** What will we call our branches?*
>> -> development (current the master)
>> -> v0.x-stable
>> -> v1.x-stable
>> -> v2.x-stable (v0.x-stable is deleted)
>> -> v3.x-stable (v1.x-stable is deleted)
>> Each branch would have multiple tags marking the minor releases.
>
>
>In general I don't care what the dev branch is called, but in my
>experience, Git-life is easier when master is the branch where development
>occurs.
>
>On Sat, Feb 13, 2016 at 8:44 PM, Andre <andre-lists@fucs.org> wrote:
>
>> I am not a git specialist but I can share my view as a user:
>>
>> ** What will master look like while we're doing this?*
>> I've noticed depending on the project a master branch can be a stable
>> branch or a development branch and as long the behaviour of the branches is
>> clearly documented, the approach used is secondary. (except on golang
>> project where rules apply).
>>
>> ** What will we call our branches?*
>>
>> -> development (current the master)
>> -> v0.x-stable
>> -> v1.x-stable
>> -> v2.x-stable (v0.x-stable is deleted)
>> -> v3.x-stable (v1.x-stable is deleted)
>>
>> Each branch would have multiple tags marking the minor releases.
>>
>> Ditching master as a name will clearly state the intent of the branch and
>> allow the user / developer to know that by running on that version you are
>> from cutting edge.
>>
>> Having said that I suspect there are some minor issues about getting a git
>> without master to run on github [1]but given the project uses the ASF bot
>> and github replication it may worth checking if this is possible.
>>
>> Independently of the name master would be cutting edge and things could
>> break.
>>
>> ** Who would integrate patches and PRs into multiple versions?
>> Reviewer? Submitter? Or would this be another ticket?*
>>
>> If it is a new feature (e.g. new listener) it should be up to the submitter
>> to decide if support would be extended to currently stable release or would
>> reside just on the development branch.
>>
>> The key IMHO aren't the features but changes to shared code; as long we
>> prevent changes to existing classes and method signatures I think we would
>> be following the right track.
>>
>> It should be paramount to provide stability to code crafted outside the
>> project (a perfect example being NATS messaging processor that was never
>> merged into the project [2]) without hindering development of the product
>> within minor releases.
>>
>> Regarding bug fixes, I think anyone would be welcome to submit a fix to any
>> of the supported branches.
>>
>> ** What project does this well and could be a model?*
>>
>> I think a good model to look at is the one adopted by rsyslog project.
>>
>> If I'm not mistaken they adopt a release branch model.
>>
>> v7.x is no longer improved but still available for bug fix backport into
>> minor releases (controlled via tags).
>> v8.x stable is there and has tags for each of the minor releases.
>> master is the development tree
>>
>> ** Should we decide to only have one version "supported" at a time to
>> avoid this?*
>>
>> I reckon that nowadays the minimum expected by user base is major - 1 as
>> this prevents the requirement to adopt rolling releases.
>>
>> Also, by supported I mean security fixes and critical issues that may lead
>> to data loss and system crashes. features, nice to haves and other things
>> are up to a number of factors and I may or may not get them backported.
>>
>> Those who have ever dealt with RHEL know that you may ask RH to backport
>> feature blah to "version - 1"... you may ask, but truth is that sometimes
>> you will get it, sometimes you won't.
>>
>> Cheers
>>
>>
>> [1] https://matthew-brett.github.io/pydagogue/gh_delete_master.html
>> [2] https://github.com/mring33621/nats-messaging-for-nifi
>>


Mime
View raw message