Don't generate "import-package" version restrictions for preliminary APIs (i.e. major version being 0)

[kwin]

By default bnd generates version restrictions for Import-Package headers according to the import version policy. However APIs having a major version 0 are unstable by definition. As in general for unstable API it is impossible to predict which future versions may be compatible or not bnd should in that special case not automatically create version restrictions (no matter if provider or consumer). However a warning during the build should be emitted that one depends on an unstable version.

This was triggered from #6691.

[laeubi]

However APIs having a major version 0 are unstable by definition.

I think ther is a misunderstanding her, even though both are named SemVer and are quite similar, the OSGi specification of SemVer is here, and it specifically distinguish between consumer and provider ranges but there is no such thing like "preliminary" API so whatever you export is API and should comply to the version rules from day 1.

Also importing such API without any version range is actually very bad as it will bind to any higher version, regardless of how it evolves in the future.

[kwin]

@laeubi The reference to https://semver.org/#spec-item-4 is from the bnd code (https://github.com/bndtools/bnd/blob/28ee79bf1ee0a68d12c599cceafca679ac1c7958/biz.aQute.bndlib/src/aQute/bnd/differ/Baseline.java#L319-L327). This is how Bnd is doing baselining!

[laeubi]

The semver spec defines version wich can contain hyphens that is invalid in OSGi so I doubt " This is how Bnd is doing baselining!" ...