[gdal-dev] Misc. subjects : OSGeo Vienna code sprint, release plans, GDAL 2.0

Even Rouault even.rouault at mines-paris.org
Fri Feb 21 02:07:25 PST 2014


Selon Dmitriy Baryshnikov <bishop.dev at gmail.com>:

> Hi Even,
>
> I plan to participate in code sprint too and work on GDAL.
> In addition to the mentioned tasks I would like to discuss some politics
> and direction to add new functionality to GDAL.

Great, perhaps you can share some of your thoughts ahead of time ?

>
> Best regards,
>      Dmitry
>
> 14.02.2014 1:14, Even Rouault пОшет:
> > Hi,
> >
> > I've confirmed my presence to the OSGeo Vienna code sprint (
> > http://wiki.osgeo.org/wiki/Vienna_Code_Sprint_2014 ). Are there folks that
> > will be there and indent doing some work on GDAL ? Any particular topics of
> > interest ?
> >
> > It could be the opportunity to take a crack at some changes that have been
> > mentionned for some time and are listed at
> > http://trac.osgeo.org/gdal/wiki/GDAL20Changes
> >
> > We should decide how to manage the 2.0 transition. I think that the 2.0
> number
> > should be reserved as the opportunity of introducing breaking changes in
> the
> > API / ABI. But this might take a long time to implement all that is listed
> > above, so there's a risk we end up with a trunk that is never ready for
> > release for years. Not a good thing.
> > On the other hand, we could just be more modest and take breaking changes
> as
> > they are introduced and raise the major version number (so the yearly
> version
> > after 2.0 could be 3.0). This will require projects using GDAL to adapt
> > multiple times.
> > An alternative would be to prepare the API for new features even if they
> are
> > not implemented, but that's a difficult exercise and there's a risk that at
> > implementation time, the API doesn't fit.
> > Any thoughts ?
> >
> > Currently we have no such breakage in trunk so it could qualify as GDAL
> 1.11.
> > Perhaps we should just release it as such for now before the bigger changes
> ?
> >
> > Somes topics I can see for GDAL 2.0 that impact API/ABI :
> > - well, the mythological unification of OGR driver model with GDAL driver
> > model.
> > - XYZM support
> > - Curve geometries
> > - 64 bit integer support
> >
> > Other possible structural changes :
> > - Change of master version control system: switch to git / GitHub ?
> > - New build system : cmake ?
> >
> > Of course all of this will more likely happen if contributors or funders
> show
> > up !
> >
> > Even
> >
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev






More information about the gdal-dev mailing list