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

[Philippe P Mulet <philippe_mulet@xxxxxxxxxx>]

My view is that an API change may be
a contract change, with no signature change. There API tooling is going
to be tricked.
So in essence, even though API tooling is suggesting no signature change
occurred, there could really be some.

Also, to all, a plugin version change is to be considered as an API change,
and agreed before committing the change.

Martin Aeschlimann <martin_aeschlimann@xxxxxxxxxx>
Sent by: eclipse-dev-bounces@xxxxxxxxxxx

05/13/2008 12:09 PM

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

To	"General development mailing list of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>
cc
Subject	Re: [eclipse-dev] Ant build submission -- down        leveling        plugins        versions after API freeze

> Since no API was changed in a compatible way since 3.1, the bundle
> minor version was not supposed to change.

I personally think there is nothing wrong for a bundle to increase its
version number even if no API addition or change happened.
Let's say the bundle got considerable work over the year, with non-trivial
behavioral changes (major fixes, new features, different UI..) it's more
than fair to also increase the minor number. API isn't always describing
everything a bundle does.
Bundles that specify a dependency to an other bundle of a certain version
are mostly tested only against that version and might look bad with the
new
reworked bundle, although they compile fine. If they limited themselves
to
something like [3.2.0,3.3.0) then the shouldn't expect more than just some
bug fixes.

> If you don't rely on such new API,
> you should *not* change the version range.

I think it's better to make the version range as precise as possible to
the
version of the plug-in you normally run against and test against.
Our plug-in might still compile against 3.3, but does it really run with
3.3? Can we promise this without really testing it? For example the UI
we
added for external class folders doesn't make sense to have with a 3.3
jdt.core that doesn't offer external class folders. There was no real API
change here that API tooling could detect, only a spec change that said
that classpath entries can now point to external folders as well.

These comments are of course just general comments and the situation of
ant.core is probably different (I assume there were only bug fixes). Maybe
Olivier didn't intend to make general statements here. But I'd be happy
if
the PMC can clarify this so the API tooling doesn't issues wrong
warning/errors here

Martin


                    
                     
                     
                     
                     
                
  From:       Olivier Thomann <Olivier_Thomann@xxxxxxxxxx>
                     
                     
                     
                    
                     
                     
                     
                     
                
  To:         "General development mailing
list of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>  
                     
  
                    
                     
                     
                     
                     
                
  Date:       12.05.2008 15:46      
                     
                     
                     
                     
                    
                     
                     
                     
                     
                
  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



Sauf indication contraire ci-dessus:/ Unless stated otherwise above:
Compagnie IBM France
Siège Social : Tour Descartes, 2, avenue Gambetta, La Défense 5, 92400
Courbevoie
RCS Nanterre 552 118 465
Forme Sociale : S.A.S.
Capital Social : 542.737.118 €
SIREN/SIRET : 552 118 465 02430