|
Alexander,
Comments below.
On 13.09.2016 11:33, Alexander Nyßen
wrote:
Ed,
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.
Cheers,
Alexander
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?
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tools-pmc
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer
Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743
http://www.itemis.de
alexander.nyssen@xxxxxxxxx
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
tools-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tools-pmc
|
