[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tools-pmc] PMC Approval for Oomph 1.5.0
|
Alexander,
Consulting the bible
https://wiki.eclipse.org/Version_Numbering#When_to_change_the_minor_segment
it mentions that it should happen when a plug-in changes in an
"externally visible" way. Adding a method that can be used by
downstream dependencies is obviously externally visible but the version
range used on a bundle requirement in the MANFIEST.MF is subtly
externally visible in the p2 metadata, not unlike changing the BREE.
Of course very few projects properly manage the lower bounds of their
version ranges, generally leaving them as the were at the time the range
was first created. But it's clear if I add a method to bundle A and use
it in bundle B, the lower bound of B's dependency on A should reflect
that it needs at least the version of A that has that method. It all
becomes very hard to track in a 100% accurate way because some other
bundle C might depend on B but might not use that new method so
technically it doesn't need to change the lower bound until it's
actually changed to use that new method. I suppose the API tools would
track that with the @since information, but I'm not sure.
Cheers,
Ed
On 13.09.2016 08:24, Alexander Nyßen wrote:
I did not look into any details, but simply out of curiosity: if consuming the new bundle API did not result in an API change in the consuming bundles, AFAIK incrementing the micro should have been sufficient there. What's the motivation behind increasing their minor?
