nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Percivall <>
Subject Re: [DISCUSS] narrowing in on the Apache NiFi 1.0.0 release
Date Wed, 13 Jul 2016 02:06:39 GMT
This is going to be an awesome release and I'm excited to see what others think of all the
great work that has gone into it. I would be more than happy to act as the RM for the 1.0.
I can start tomorrow looking through the tickets assigned to 1.0 and help move them towards

- - - - - - 
Joseph Percivall

On Tuesday, July 12, 2016 12:14 PM, Joe Witt <> wrote:

There has been a lot of progress for 1.0 and with 0.7 in the final
phases and the first minifi release in the mirror its time to start
pulling 1.0 together.  There are a fairly large number of outstanding
tickets most of which are there from 'back in the day' marking things
as a '1.0' fix version meaning 'the future' or habits of making
tickets and preassigning fix releases even though they're not being
worked just yet.  So cleaning a lot of JIRA stuff up but it looks like
we can start working the RC process fairly soon.

Important remaining finishing touch work is underway.  Of the
remaining 1.0 tickets an important push is to cleanup deprecated
things and leverage Apache Yetus annotations to very clearly
articulate API intent/stability/openness.  For those building on
Apache NiFi it means they'll have better clarity on what is subject to
change and not and for those building Apache NiFi itself it means we
will have more flexibility to change parts of the system which are not
considered public API.  There are a couple really exciting roadmap
items like extension/template registry that Matt/Puspendu have been
discussing lately which will also be a tremendous help for agility
with extensions too.  Other things like variable registry will be key
for that too.

This 1.0 release for those following along the master branch and
associated JIRAs has some really cool updates in it.  For example,
NiFi will now be able to support multiple editors in parallel without
the dreaded "too late you must refresh".  It supports fine grained
authorization logic rather than coarse grained 'system wide' DFM or
Read-Only which makes multiple teams working on the same system have a
far better operational capability.  The UI has been refreshed/updated
and provides a more responsive and effective basis to evolve from.

I'm happy to take on the RM work for the release but if someone else
wants to take a stab at it please advise.


View raw message