OSGI-compatible versioning of distribution and SDK modules

As discussed here, the OSGI compatibility of Ceylon modules is broken as soon as the module version doesn’t comply with the OSGI version numbering.

And OSGI version numbering is more restrictive than Ceylon version numbering, as shown by the following documentation excerpt (found here):

Versioning

OSGi allows different versions of bundles, packages, and several other entities, to co-exist in the same framework and provides some mechanisms for managing these versions.

Version Numbers

An OSGi version number consists of up to three numeric components, or exactly three numeric components followed by a string component. These components are separated by a period (“.”) and are called the major, minor, micro, and qualifier components, respectively. For example, the version 2.4.1.ga has major component 2, minor component 4, micro component 1, and a qualifier component ga. (There are restrictions on the characters that can appear in a qualifier. For example: letters, digits, underscores and hyphens are allowed; periods and commas are not.) Trailing components may be omitted along with their period (.). So, for example, the version numbers 2, 2.0, and 2.0.0 all denote the same version. This example demonstrates that 0 is assumed if a numeric component is omitted, and the empty string is assumed for an omitted qualifier.

Since all distribution modules, as well as some SDK modules, are already used inside the Ceylon IDE plugin as OSGI bundles, and more generally in order to allow using SDK modules in Ceylon applications deployed inside OSGI containers, we should not use versions such as 1.2.1-1 for distribution or SDK modules. I we do so, those modules will not be usable by the Ceylon IDE project, nor by any OSGI container.

This has already been done (for the ceylon.net SDK module for example). But for this reason, it seems to me that we should review the numbering policy we choose for the Ceylon distribution and the SDK, in order to avoid breaking OSGI compatibility (as well as Ceylon IDE development) in the future.

[gavinking]

@davidfestal So, given that we now have an algorithm for generating a reasonable OSGi version from a given Ceylon module version, does that mean we can finally stop the madness of unzipping and editing MANIFEST.MF and rezipping that is a major reason the build is currently such a nightmare?

[luolong]

Just to make things more interesting, SemVer has gotten itself a v2: http://semver.org/spec/v2.0.0.html