nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Skora <jsk...@gmail.com>
Subject Re: [DISCUSS] git branching model
Date Sun, 14 Feb 2016 02:26:06 GMT
+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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message