nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre <>
Subject Re: [DISCUSS] git branching model
Date Sun, 14 Feb 2016 01:44:41 GMT
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

** 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.



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