nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Witt <>
Subject Re: [DISCUSS] MiNiFi C++ 0.9.0 release
Date Thu, 21 Jan 2021 15:16:58 GMT

I think if consensus matches your view on api stability then 0.9.0 is most
appropriate over a 1.0 for now.  The progress made here in the past year is
really awesome and frankly knowing some of the uses of this at the scale
and diversity of usage is really exciting.

You would just remove the 0.8.0 JIRA target and ensure any tickets tagged
there are tagged to 0.9.0?  Or just go back to 0.8.0 and get rid of 0.9?


On Thu, Jan 21, 2021 at 7:55 AM Marton Szasz <> wrote:

> Hi community,
> I'd like to initiate a discussion about the next release of MiNiFi C++. The
> last release was over a year ago, and there have been countless new
> features, bug fixes and stability improvements committed to the development
> branch since then.
> Some highlights from the last year:
> - Added support for RocksDB-based content repository for better performance
> - Added SQL extension
> - Improved task scheduling
> - Various C2 improvements
> - Bug fixes and improvements to TailFile, ConsumeWindowsEventLog,
> MergeContent, CompressContent, PublishKafka, InvokeHTTP
> - Implemented RetryFlowFile and smart handling of loopback connections
> - Added a way to encrypt sensitive config properties and the flow
> configuration
> - Implemented full S3 support
> - Reduced memory footprint when working with many flow files
> Why 0.9.0 instead of 0.8.0?
> The codebase is starting to stabilize and we're getting closer to a 1.0
> milestone, but I feel like the extension API is not yet something we can
> commit to support in the long term. Additionally, a release branch for
> 0.8.0 has been created earlier, but it was not released, and with all the
> new development it wouldn't make sense to release it.
> Do you think 0.9.0 is a good target, or would you go with 0.8.0 or 1.0
> instead? Are there any blockers that should definitely make it into the
> next release?
> Thanks,
> Marton

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