OctoPrint’s versioning strategy¶
OctoPrint’s version numbers follow PEP440, with a version format of MAJOR.MINOR.PATCH following the contract of semantic versioning.
The PATCH version number will increase in case of hotfix releases 1.
Releases that only change the patch number indicate that they only contain bug fixes, and usually
only hotfixes at that. Example:
The MINOR version number increases with releases that add new functionality while maintaining
backwards compatibility on the documented APIs (both internal and external). Example:
Finally, the MAJOR version number increases if there are breaking API changes that concern any of the
documented interfaces (REST API, plugin interfaces, …). Example:
OctoPrint’s version numbers are automatically generated using a customized version of
versioneer and depend on the selected git branch, nearest
git tag and commits. Unless a git tag is used for version number determination, the version number will
also contain the git hash within the local version identifier to allow for an exact determination of the
active code base (e.g.
1.2.9.dev68+g46c7a9c). Additionally, instances with active uncommitted changes
.dirty in the local version identifier.
Up until 1.4.2, the PATCH version segment was the one increasing most often due to OctoPrint’s maintenance releases but with 1.5.0 this will fully adhere to the concepts in semantic versioning mandating only bug fixes in patch releases. Maintenance releases will henceforth increase the MINOR segment.