As a programmer using GDAL/OGR, I do not think I mind if there are API changes at major releases - especially, as with GDAL, where these are infrequent - but might be annoyed during point releases. It is reasonable to expect major new features and rationalisation at major releases, so the burden of having to edit code is acceptable. Obviously, if there are no changes, that is great ... but then it would hardly classify as a major release. <br>
<br>For my part, I have an interface library to edit - rather like a language binding for Java or Python, so I have probably only one place that will need work.<br><br>It says a great deal for the original design of GDAL/OGR that this discussion is only happening now, after several years and many point releases. Thank you, Frank.<br>
<br>Peter<br><br><div class="gmail_quote">On 20 May 2012 18:23, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@mines-paris.org" target="_blank">even.rouault@mines-paris.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi GDAL developers and users (actually, developers of other projects using<br>
GDAL ;-)),<br>
<br>
This issue was raised incidently in the "[gdal-dev] VRTComplexSource with a<br>
LUT, proposal" thread at <a href="http://lists.osgeo.org/pipermail/gdal-dev/2012-%0AMay/032872.html" target="_blank">http://lists.osgeo.org/pipermail/gdal-dev/2012-<br>
May/032872.html</a> .<br>
<br>
I think it is good time to discuss now what we want to allow, or not, for GDAL<br>
2.0, as far as the C/C++ API is concerned.<br>
<br>
---------<br>
C API<br>
---------<br>
<br>
Up to now, the signature of functions added in the GDAL/OGR C API has never<br>
changed, once they have been added.<br>
<br>
What should be the rule for GDAL 2.0 ?<br>
<br>
1) do not change the signature of any function already present in the C API.<br>
If breaking changes are necessary, then introduce "FooEx", or "Foo2" versions<br>
of those functions as done in the past. The drawback of that approach is that<br>
the API becomes cluttered.<br>
<br>
2) do not change the signature of any commonly used functions, but allow<br>
changes in marginally used functions. The definition of commonly functions<br>
w.r.t marginally used ones is a bit arbitrary. Looking at the symbols used by<br>
popular Open Source software using GDAL C API could give a clue in case of<br>
doubt (MapServer, QGIS, GRASS, PostGIS, or in-tree GDAL utilities using C API<br>
...).<br>
<br>
3) allow changes even in commonly used functions.<br>
<br>
Options 2) or 3) would likely require other projects to have #if GDAL_VERSION<br>
>= 2000 in some places if they plan to support older GDAL versions. Unless<br>
they plan to update their dependency requirements when they release a newer<br>
version of their project (Project XX version < 1.Y depends on GDAL < 2.0.<br>
Version >= 1.Y depends on GDAL >= 2.0).<br>
<br>
-------------<br>
C++ API<br>
-------------<br>
<br>
As far as the C++ API is concerned, the policy up to now was that minor<br>
changes between GDAL 1.X version and GDAL 1.(X+1) were OK. Generally, the<br>
changes have been the addition of new optional arguments, that only required<br>
recompilation to solve the change of ABI, but did not require code changes.<br>
<br>
For GDAL 2.0, I believe that most major changes could occur, especially if the<br>
OGR "grand unification" occurs, but for now, I don't know the impact that that<br>
might cause.<br>
<br>
-------------------------------------------------<br>
Syntax of command line utilities<br>
-------------------------------------------------<br>
<br>
A bit out of topic, since it is about UI and not API. But a lot of scripts in<br>
the wild call popular GDAL command line utilities. Changes in their syntax<br>
would cause potentially more headaches, given the larger number of users<br>
w.r.t. developers using GDAL ;-) The page at<br>
<a href="http://trac.osgeo.org/gdal/wiki/GDAL20Changes" target="_blank">http://trac.osgeo.org/gdal/wiki/GDAL20Changes</a> lists a few changes that have<br>
been proposed (just as a reminder : nothing listed there is officially vetted).<br>
<br>
The same question also arise with the API of the various bindings languages.<br>
<br>
Feedback welcome !<br>
<br>
Best regards,<br>
<br>
Even<br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>----------------------------------------------------------------------------------------------------------------<br>Peter J Halls, GIS Advisor & Team Leader Applications Support and Training, <br>
Information Directorate, University of York<br>Telephone: 01904 323806 Fax: 01904 323740<br>Snail mail: Harry Fairhurst Building, University of York, <br> Heslington, York YO10 5DD<br>This message has the status of a private and personal communication<br>
----------------------------------------------------------------------------------------------------------------<br><br>