[gdal-dev] GDAL 2.0 plans/schedule ?

[Even Rouault]

Hi Ari,

> There hasn't been much talk about this. We have of course this
> 
> http://trac.osgeo.org/gdal/wiki/GDAL20Changes
> 
> and maybe it should be checked for what is going to happen and what not.

I've updated the status of the implementation of the proposed changes:
http://trac.osgeo.org/gdal/wiki/GDAL20Changes?action=diff&version=34

> 
> I have some free time in the next weeks so I plan to go through the Perl
> API and make some changes, some will break the existing API but those
> will be in areas that have been made by Swig and not touched by me. I'll
> make a list of breaking changes.
> 
> One principle I want to enforce is the use of strings for constants
> (like data types, resampling methods etc.) in the API. I may
> discover/invent some other things while I work through the API.

If there are breaking changes, I encourage you to document them in 
MIGRATION_GUIDE.TXT at the root of the source tree.

> 
> One thing which is what we could do is to do some house keeping in the
> swig/include, which is a horrible mash of #ifdefs etc. Maybe some of the
> language specifics could really be moved to language specific
> subdirectories.

I agree it is getting messy. Sorting that out might not be easy.
One thing that made it messy was linked to RFC 46 with OGR depending on GDAL, 
and this caused issues because of interdependencies between .i files and the 
package namespaces (gdal, ogr). Particularly with CSharp.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com