Allow Baselining for 0.x versions

[chrisrueger]

... baselining to also work on 0.x packages.

Originally posted by @peterkir in #6702 (comment)

Currently in the baseline feature there is a special handling for versions < 1.0
From: https://bnd.bndtools.org/chapters/180-baselining.html#setting-up-a-project-for-baselining

the bundle/package version must be 1.0.0 or above. If the version is less (i.e. major version being 0) no baselining is possible, the purpose is to allow the primordial baseline to be established without errors.

In the discussions in #6702 it was suggested that this special handling should be removed and baselining should work for all versions including 0.x

History

The following issue and commit seem to be how this feature was created.

• bnd-baseline-maven-plugin: Skip baselining if major version is 0? #2452
• 1cc175b

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

Lines 264 to 273 in 1cc175b

	/**
	* "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;
	}

Configurability

TODO this needs to be discussed. Probably this new behavior should be opt in, to be backwards compatible

[kwin]

For the record: I think the current behavior is good (at least by default). I don’t feel the need to change it. However as stated before I would rather change the import version range policy to be incline with that default behavior

[laeubi]

I can't find any statement about this in the spec that a version < 1 has any special meaning in OSGi the only thing the spec states is that if you do not specify a version on an exported package it defaults to 0.0.0 (what could not be baselined for obvious reasons).

Of course baslining itself is nowhere specified so one could of course do it the way here it just don't sound useful:

1. If I care about consumers (of any kind) I would use baselining.
2. If my project defines a policy that API can change any time I would still like to get warnings/errors (and maybe then suppress them if I feel its is covered by the policy)
3. If I don't care in any way I won't enable baslining until version 1.x is released.

[chrisrueger]

@kwin @laeubi Peter @peterkir has started #7076 to adress this. Feedback appreciated.