Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-dev] Ant build submission -- down leveling plugins versions after API freeze


Inactive hide details for Olivier Thomann---05/12/2008 09:53:13 AM---eclipse-dev-bounces@xxxxxxxxxxx wrote on 2008-05-12 03:56:Olivier Thomann---05/12/2008 09:53:13 AM---eclipse-dev-bounces@xxxxxxxxxxx wrote on 2008-05-12 03:56:50:


Olivier Thomann/Ottawa/IBM@IBMCA


"General development mailing list of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>


05/12/2008 09:53 AM


Re: [eclipse-dev] Ant build submission -- down leveling plugins versions after API freeze

eclipse-dev-bounces@xxxxxxxxxxx wrote on 2008-05-12 03:56:50:
> It seems to me there's been several cases (already) of these new tools
overriding plain
> 'ol common sense and if the tools do not allow you to use common sense
(or, even
> encourage you to use your own judgement), then there's a flaw in your
First of all, the tool did catch a wrong version change in the ant.core
bundle. Since no API was changed in a compatible way since 3.1, the bundle
minor version was not supposed to change.

Now this leads to a second question where no tool is the culprit. If you
have a dependency against ant.core and you change the version range to be
[3.2, ...) instead of [3.1,...), this means that you rely on a new API
from ant.core that was added after 3.1. If you don't rely on such new API,
you should *not* change the version range.

> I have no idea why it was so important to fix this small error in
versioning this late,
> which to me is equivalent to an API change - and, honestly, I hope
someone tells me why
> it is so beneficial in comparison to the great costs:
So yes, the tool (api tool) discovered a wrong minor version change. Yes,
this was a late change that should have been probably more advertised to
the cross project mailing list or request a pmc approval.
Yes, this was not caught by the API freeze check because it doesn't check
the bundle versions. I can add that check for bundle version if you
believe this is an API change. But the question remains that dependent
bundles on ant.core should have not changed their version ranges.
This is something we plan to add to API tool post 3.4 so that this kind of
wrong dependency range change would be discovered earlier.

> Oh, and I really do not like flame wars, but am always open to
constructive criticism or
> just plain 'ol education if I am the one missing the obvious.
So to stay constructive, could you please explain me why the version range
was changed?
eclipse-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

GIF image

GIF image

Back to the top