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!

Anonymous
Parents
  • Hey!
    Thanks for Updating us.

    I just want to ask about Semantic Versioning 2.0.0 that if versioned package released what changes we will see in Content of that version? Thinking

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

  • Do you have any plan to trigger an automatic uninstall in case of major change?

    I would rather keep managing any checks or user warnings in the actions files.
    Still if you have any plans I would like to take them into account now rather than later.

    Kind regards,
    Laurent

Comment
  • Do you have any plan to trigger an automatic uninstall in case of major change?

    I would rather keep managing any checks or user warnings in the actions files.
    Still if you have any plans I would like to take them into account now rather than later.

    Kind regards,
    Laurent

Children
No Data