nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aldrin Piri <aldrinp...@gmail.com>
Subject Re: 1.0.0 Branch Guidance
Date Tue, 29 Sep 2015 12:48:57 GMT
Dan,

I don't think we are at the point where 1.0 is our next release.  The items
to be included for that release as per the feature proposals (whether
directly as a feature or as an implicit dependency for one or more of those
features) are some considerable efforts and while there may not be many
releases between 0.3.0 and that point, it will likely be too long to go
without any at all.

Certainly agree on the long living branch being an effort of itself, but
may be the course we have to take to keep the project moving.

On Tue, Sep 29, 2015 at 8:41 AM, Dan Bress <dbress@onyxconsults.com> wrote:

> Aldrin,
>    I definitely like the idea of creating separate branches for the 0.3.X
> work and the 1.X.X work.
>
>    My thoughts would be to make 'master' the 1.X version, and make a
> branch for the 0.3.X work.  The reason being, I would imagine most of the
> work the community is doing should be slated for 1.X, where as less
> work(e.g. bug fixes) be done in the 0.3.X branch.  And by making master
> 1.0.0 it nudges people in that direction.  Also, I'm assuming that 0.3.X
> will just be bug fixes at this point, and our next 'major' release will be
> 1.0.0.   Is that a fair assumption to make?  If not, I might be more
> inclined to agree with your original suggestion, although keeping that long
> living branch up to date with all the changes from master might be a
> maintenance nightmare.
>
> Dan Bress
> Software Engineer
> ONYX Consulting Services
>
> ________________________________________
> From: Aldrin Piri <aldrinpiri@gmail.com>
> Sent: Thursday, September 24, 2015 10:49 AM
> To: dev@nifi.apache.org
> Subject: 1.0.0 Branch Guidance
>
> All,
>
> We are starting to receive more items that are "breaking" changes
> (deprecation of components and code being those that immediately come to
> mind) and are accordingly scheduled for a 1.0.0 release.  I would like to
> solicit the community for best practices on the introduction and
> maintenance of a 1.0.0 branch so we can do so in a practical manner.
>
> There are a few PRs/patches that are sitting in limbo because we do not
> have an appropriate place to put them and would very much like to be able
> to incorporate those changes and close them in lieu of waiting until master
> reaches that juncture.
>
> Any input on caveats, items to note, and any other items to be mindful of
> is greatly appreciated.
>
> Thanks!
>

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