|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?
Back to the top