nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Witt <>
Subject The next release and beyond
Date Thu, 04 Jun 2015 03:37:05 GMT

So we had a decent thread which described the sort of high level
themes folks want to see on the roadmap.  Most of it was pretty large
scale stuff in terms of time/impact/etc.. so unclear when some of that
will occur just yet.  Much of it centers around the need to review and
consider the clustering model into the future.  There are many JIRAs
out on that now so that topic is well in hand.  So to get more
specific about the next release or two as far as the plan appears to
be shaping up let's take a look.

We had plenty of tickets slated as 0.1.1 and certainly enough there to
justify a release as basically pure bug fixes.  However, we applied a
contribution to develop which adds support for interaction with
MongoDB so that pushes us to 0.2.0 following the semver concepts
outlined earlier.  No biggie - we just move forward.  This means that
the next release will be 0.2.0.  So I've renamed the previously
existing JIRA version 0.2.0 to 0.3.0 and the existing 0.1.1 to 0.2.0.

In the morning I'll plan to bump the versions on develop from
0.1.1-incubating-SNAPSHOT to 0.2.0-incubating-SNAPSHOT.

Here you can see what is targeted for an 0.2.0 release:

0.2.0 is basically:
- Lots of bug fixes
- Few simple feature enhancements
- Support for MongoDB
- Support for Storm Spout

And here you can see for an 0.3.0 release:

0.3.0 is:
- Bug fixes and feature enhancements
- New Nar Plugin to provide a convenience goal to under dependencies
- New feature enabling DFM to interact with data on the queues -
visualize them, edit them, etc..
- ...and more

For those interested to see their existing contributions or planned
contributions make it into the next release (0.2.0) please advise.
Best way to do so is to ensure there is a JIRA for it and that it is
mentioned as being associated with a fix version of 0.2.0.

There is also a bit of a 1.0.0 release set of tickets starting to
shake out.  These are things which will affect backward compatibility.

...i wonder if we should pursue some sort of sprint-planning or
release planning sort of concept.  It isn't clear to me how such a
construct could best work here.


View raw message