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
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

The Apache NiFi (incubating) project aims to follow versioning principles as described at Semantic Versioning 2.0.0

Consider the following scenarios in the context of the most recent 'example' release being 0.0.1.

  • For releases which are comprised solely of bug fixes or non-feature introducing or enhancing changes that requires only a 'patch' version bump (the Z part in X.Y.Z).  So the next release then is 0.0.2.
  • For releases which include backward compatible changes to introduce feature enhancements or new features that requires a 'minor' version change and the 'patch' version resets to '0' (the Y part in X.Y.0).  So the next release then is 0.1.0.
  • For releases which include non-backward compatible changes or changes deemed so substantive by the community that it is considered a 'major' version change and the minor and patch versions reset to '0' (the X part in X.0.0).  So the next release then is 1.0.0.

After a release occurs the 'patch' version will be automatically adjusted by maven without the release manager doing anything special.  So rarely will this value need to be manually set.  In the event of a 'major' or 'minor' bump though the entire relevant source tree will need to be adjusted.  That can be accomplished by using the following commands:

mvn versions:set "0.1.0-SNAPSHOT"
mvn versions:commit

It is important that we also define the notion of 'compatibility' and what we're talking about.  The most obvious scenario here is code compatibility of APIs and features and so on.  However, we must also keep in mind compatibility of configuration items like properties files and of our runtime API's like the REST API to interact with a running NiFi instance.  All of these are critically important to both developers, clients that interface with NiFi, administrators that configure it, and users that interact with NiFi in operations.

Special consideration: You must also consider 'compatibility' of processors and extensions specifically.  For example, if a processor has two relationships and you add a third one or remove one you must be sure to take extra care to document this sort of thing for the release that it goes into.  We should always provide a notice to folks upgrading from version to version so they know what to look out for.  Those cases are usually easily resolved by simply knowing that after upgrading they need to specify a relationship and start that processor or that they need to remove a no longer relevant relationship.  But the key is to ensure we follow through with effective notices for users so they understand what is happening and don't simply perceive a bug or issues introduced by upgrading.

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.  

It is not always clear what the right answer is for whether something is a 'patch' or 'minor' bump whereas 'major' should be pretty obvious.  Changes to major should signal a potentially high risk but high reward scenario for would-be users.  Changes to 'minor' and 'patch' though they should feel a relatively high degree of confidence in downloading and upgrading their system.  That is something we'll have to earn as a community and it starts by following the guidance closely and adjusting it as we learn more.  If unsure please initiate a dialog on the dev mailing list.  This is really important information for those with commit privileges or who are reviewing contributions.  Has the contributor properly accounted for the version change implications?  If someone is providing a new feature or enhancement when merging that change you may need to adjust the version of the develop branch and the contribution to accommodate it.

  • No labels