How to version your Module Loadable Packages

Up until today, we have not defined a strict format for how developers should version their Module Loadable Packages. This occasionally can cause problems when Sugar tries to parse or compare these version strings.

Today, we're updating our guidance on the version format. We now expect developers to use the Semantic Versioning 2.0 standard for package versioning. Semantic versioning not only requires a specific format, but it defines a helpful methodology for how and when you should be incrementing your version numbers. This gives everyone that works with packages, including Sugar Admins and end Customers, a consistent understanding of what it means to upgrade from one particular package version to another one.

Compliant Versions

$manifest['version'] = '1.0.0';
$manifest['version'] = '2.1.5';
$manifest['version'] = '0.1.0';

Non-compliant Versions

$manifest['version'] = 'v1.0.0'; // no leading 'v' character
$manifest['version'] = '6787654675'; // Don't leave off MINOR and PATCH versions
$manifest['version'] = '0.1.alpha'; // numbers only for MAJOR, MINOR, and PATCH

We have also updated the Manifest Definition documentation and package examples in the Sugar 11.0 and 11.1 Developer Guides to reflect this new guidance.

Take Action!

Please update any non-compliant version strings in the Module Loadable Packages that you have developed or maintain to use semantic versioning. There is no plan today to strictly enforce this format but if that changes then you, my friends, will be the first to know!

Parents Comment
  • If I follow your question, the idea with semantic versioning is that you'd change the MAJOR version value only when you introduce functionality that would break or change existing functionality. You'd change the MINOR version when you're adding new features without breaking changes. And PATCH is for bug fixes only.