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


> So to stay constructive, could you please explain me why the version range
> was changed?


It was just part of a general "cleanup" of scores of pre-req ranges. Over time we've ended up
with many different (inconsistent) versions in pre-req ranges some wide, some narrow, with different lower ranges usually
chosen based on what was current at the time ... not necessarily the lowest possible that contained
the API we were using. So we wanted to get a fresh start, where we were internally consistent,
especially since next release it will be much more important to us to be accurate.

While I know it's possible, and in many cases desirable, there's no rule that
says we _have_ to pre-req the _lowest possible_ version of a plugin.
In fact, some argue that since we don't test with the lower versions we should not claim we
still work with them, especially when there is no business need to, and
especially since as a whole we (WTP) do not work with the previous version of Eclipse, so
it doesn't much matter if one isolated plugin just uses some API from a lower level of a plugin
that we claim in our range. BTW, some Projects at Eclipse (EMF, I think) (and some _products_
I've heard of) automatically change their lower bound pre-req range to be that in the version of
eclipse they pre-req. These of course wouldn't have been broken by your change since they do it during
their build!

So, while you say "If you don't rely on such new API, you should *not* change the version range."
you should remember that is your project's policy ... not all projects (and products) have the
exact same policy as you do.
 
But, we all have agreed on an API freeze date, and yes, I consider bundle versions as API, doesn't everyone?
As with many other things, there comes a point you have to live with a less-than-clean aspect of your code,
rather than cause other problems for other people.






From: Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>
To: "General development mailing list of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>
Cc: "General development mailing list of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>, eclipse-dev-bounces@xxxxxxxxxxx
Date: 05/12/2008 09:58 AM
Subject: Re: [eclipse-dev] Ant build submission -- down        leveling        plugins        versions after API freeze





+1

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:

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
_______________________________________________
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


Back to the top