This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • Version Scheme and API Compatibility

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Even within the concept of code compatibility, though, there can be some ambiguity. We should consider code to be 'backward compatible' (and therefore allowed in a 'minor' version change) if the change in X.Y.0 allows all extensions (Processors, Reporting Tasks, Controller Services, and Authority Providers) that are developed against the X.(Y-1).* API to still perform their tasks the same way. For example, it is not backward compatible to remove or change the signature of a method in the 'FlowFile' interface because Processors may no longer function properly. It is, however, acceptable to add a new method to this interface because it is expected that only the Framework will be implementing this interface. Therefore, all extensions will still function properly.

Also, starting with the Apache NiFi 1.x codebase we have adopted Apache Yetus 'Audience Annotations' to explicitly mark code for things like interfaces, classes, and methods to indicate the intended audience and stability of those APIs.  If not otherwise marked please consider the interface, class, or method to be private/internal and unstable.  The vast majority of 'nifi-api' should be both public use and stable meaning we will treat any compatibility changes for these items as things which would likely require a major release.  Otherwise, as a community we should be able to more easily navigate the necessary evolution and improvement of the codebase for these interfaces, classes, and methods for which we do not have to be so strictly adherent to backward compatibility.  A further consideration here though is as mentioned previously which is that even if we want to change classes, interfaces, and methods which are not public and stable we must also be mindful of things like configuration, user experience, REST API, etc... as these are also an important part of our 'interface' and compatibility which we must honor and account for.

Given that NiFi itself is designed for extension and the growing community is providing frequent contributions in the form of feature enhancements and new features the most likely scenario in a given release is that it will be a 'minor' version bump.