Gavin King

Thanks!

I personally think completely independent version numbers would be hell. I prefer the scheme proposed by @chochos which is essentially what we've been doing until now. If necessary, we could...

> What advantage would that have and how would it be less of a "hell"? Well the point is that it should at least partially satisfy folks who are attached...

> yes, exactly, it's incompatible with the OSGI support : That's rubbish. The OSGi module descriptor transpiler can _easily_ chop off one of the versions.

> @tombentley perhaps I’m missing something, but aren’t you essentially asking for [SemVer](http://semver.org)? SemVer is a cargo cult. It solves no interesting issues in software engineering.

Note that my proposal assumes that the SDK release cycle remains coupled to the compiler release cycle. If that's _not_ going to be the case in future, then the first...

@davidfestal currently, we generate a manifest that looks like this: ``` Manifest-Version: 1.0 Bundle-SymbolicName: interop Export-Package: interop;version=1.0.0 Bundle-Version: 1.0.0.v20160302-1224 Require-Bundle: ceylon.language;bundle-version=1.2.2;visibility:=reexp ort,com.redhat.ceylon.dist;bundle-version=1.2.2;visibility:=reexport Bundle-ManifestVersion: 2 Bundle-ActivationPolicy: lazy;exclude:="*" Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version>=1.7)) " ```...

The name of the `.car` is irrelevant, since for OSGi we have to rename it anyway.

> do we still consider that the module version (without the platform version) is unique. Yes. > That means the platform version in only informative. Right. > Such a case...

@davidfestal I mean "you" as in your `MANIFEST.MF` generator.