Page History

...

• 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.

...