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

[Kyle Shannon]

Hi,  Just a few thoughts/questions...

On Thu, Feb 13, 2014 at 2:14 PM, Even Rouault
<even.rouault at mines-paris.org> wrote:
> 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.

How long would the stable branches be maintained?  Would we handle as
we do now, with one stable branch and one development branch, or would
we backport bug fixes to n branches (3.1, 2.4, etc)?  Would this
require maintaining 3 branches?  stable, trunk, and api_break?  Any
thoughts?

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

Maybe release 1.11 soon, and take a crack at 2.0 changes before the
next release?  This would probably require a concerted effort from
developers or funders, as Even mentioned in regard to the sprint.

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

The 64-bit integer changes seem fairly straight forward.  I see XYZM
support up for GSoC again, maybe it'll get picked up.  I have no idea
what curve support would entail.

>
> Other possible structural changes :
> - Change of master version control system: switch to git / GitHub ?
> - New build system : cmake ?

What are the benefits here?  Is travis integration easier?  I believe
someone has a cmake port floating around on github, any comments
there?

>
> Of course all of this will more likely happen if contributors or funders show
> up !
>
> Even
>
> --
> Geospatial professional services
> http://even.rouault.free.fr/services.html
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

Regards,

-- 
Kyle