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 (

bnd/biz.aQute.bndlib/src/aQute/bnd/differ/Baseline.java

Lines 319 to 327 in 28ee79b

	/**
	* "Major version zero (0.y.z) is for initial development. Anything may
	* change at any time. The public API should not be considered stable."
	*
	* @see <a href="https://semver.org/#spec-item-4">SemVer</a>
	*/
	private boolean mismatch(Version older, Version newer) {
	return older.getMajor() > 0 && newer.getMajor() > 0;
	}

). 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!" ...