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

[Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>]

+1

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

From:	Olivier Thomann/Ottawa/IBM@IBMCA
To:	"General development mailing list of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>
Date:	05/12/2008 09:53 AM
Subject:	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 
tools! 
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?
--
Olivier
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev