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

[Even Rouault]

Thanks for your thoughs Kyle. I expect more developers and PSC members to 
express theirs too.

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

What would be the api_break branch, as opposed to trunk I mean ?
Maintaining 2 branches in addition to the development branch seems to be a bit 
too much work. Well, backporting is not that difficult generally, but releasing 
a version is an effort that takes some energy and time, so we would have likely 
difficulty in making the necessary releases. But anyone wanting to maintain a 
branch can do it, so there's no need to set that policy in stone.

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

Well, new geometry types and enhancements in drivers that would support them 
(PostGIS, ...). And also likely adapt all existing drivers that have write 
support so they can deal with the new geometry types : ignore them, or take 
them into account.

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

Well, I put that on the table since it is sometimes mentionned by developers, 
but the effort vs benefit ratio is not completely obvious for existing GDAL svn 
commiters.
git transition would be mainly to keep up with what developers are of will 
soon be familiar with. Someone pointed me recently that GitHub also exposed 
git repositories as subversion repositories (which I experimented a bit), so 
that could satisfy most developers. git has the benefit of easing porting 
patches between branches, and making contributions from casual developers 
easier. Since the git mirror already exists, the transition to github would 
essentially require porting the Trac database to Github tickets (we could 
benefit from MapServer experience that has done that move before)

> I believe
> someone has a cmake port floating around on github, any comments
> there?

The effort seems to have stalled. The benefit here would be the unification of 
the Unix and Windows makefiles, but the complexity of GDAL dependencies makes 
the porting effort rather repelling...

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html