Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tools-pmc] PMC Approval for Oomph 1.5.0


Comments below.

On 13.09.2016 11:33, Alexander Nyßen wrote:

of course the lower bounds of a bundle’s requirements need to be properly maintained. And I agree that this is often not done. As I think it basically boils down to missing tooling, let me mention that I recently supervised a bachelor student who worked on extending PDE's API tools to add a check for this. Hopefully he will soon manage to get in a shape so it can be contributed to PDE.
Well, Oomph has its Version Builder tool, and we use that with Oomph (and I used it for EMF and XSD) to ensure that things do get incremented.  Optional checks include checking lower bounds match the actual version of the dependency.  All with quick fixes to fix the problems. 

What I was wondering about is that the increase of a minimal required version was regarded as an externally visible change that needs to be reflected in a minor increment. I interpreted this differently so far and have only increased the micro in such a case, as from a consumers point of view the bundle is still compatible (assuming the increased minimal dependency is not reflected in its own API).
It's certainly subject to interpretation.  We use our Version Builder tool and it at least keeps everything consistent.  Perhaps we increment more than necessary, but that seems better than less than necessary.  At the start of each release train cycle, increments to the platform's root features have been overlooked.  Perhaps this year will be different.


Am 13.09.2016 um 08:44 schrieb Ed Merks <ed.merks@xxxxxxxxx>:


Consulting the bible 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.


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?

tools-pmc mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Dr. Alexander Nyßen
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino

tools-pmc mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top