not really, we just "bump to current release version", also "artifact
level" is way to broad to be really useful.
No, some people do that. But it's not a requirement nor what's preferred. I personally always increase the micro segment only whenever possible. However, bumping by +0.0.1 or +0.0.N doesn't make a difference in practice, that why both approaches are tolerated in m2e.
What need to be avoided is bumping by +0.1.0 where +0.0.N would be sufficient.
In fact the artifact version
should be the maximum version of all export-package versions.
Major and minor yes, micro no.
probably yes, but it seems it is not used anywhere.
People don't using a standard solution is rarely resolved by building another custom solution, It just mean the people don't care about this problem enough to try mitigate it. It's a behavioral problem (usually not important enough to be worrying) of consumer, not a technical limitation causing that.
We should also
strictly discourage using require-bundle as it hinder us to move code
around.
We should clearly state then that this "release-version" has nothing to
do with the bundle/package version.
Right. Any idea where this could fit (ie where would that target audience stumble upon this info)?
"exported non-internal packages" are a real strange thing, we should not
use that as this is complete eclipse specific.
Because it's focused on the grain on 1 bundle and not of a whole software piece, OSGi misses an important point about "internal APIs" which are things you want to expose to bundles that are build and shipped and tested together but don't want to maintain as a public API. There is a real need for it, and the x-internal/x-friends is so far the only viable solution as far as I'm aware.
Or maybe there is some other mechanism I've been missing to cover that case?
- https://enroute.osgi.org/FAQ/210-semantic_versioning.html
[...]
Sure Eclipse always has had its own "standards", but here I'm
referencing to what most developers understand when using the term
semantic versioning :-)
