[gdal-dev] Which version number for the next GDAL release : 1.10 or 2.0 ?

[Even Rouault]

Le jeudi 08 novembre 2012 23:09:16, Frank Warmerdam a écrit :
> On 12-11-08 01:49 PM, Even Rouault wrote:
> >> I appologise to Howard or others who have been tuning configuration
> >> logic for a 2.0 release.
> > 
> > It depends on how they have tuned...
> > 
> > We have a small technical detail to solve with 1.10 because of
> > #  define GDAL_VERSION_NUM
> > (GDAL_VERSION_MAJOR*1000+GDAL_VERSION_MINOR*100+GDAL_VERSION_REV*10+GDAL_
> > VERSION_BUILD)
> > 
> > With the current definition 1.10 and 2.0 would resolve to 2000...
> > Annoying.
> > 
> > So we would need to redefine it likely as
> > 
> > #  define GDAL_VERSION_NUM
> > (GDAL_VERSION_MAJOR*1000000+GDAL_VERSION_MINOR*10000+GDAL_VERSION_REV*100
> > +GDAL_VERSION_BUILD)
> > 
> > and 1.10 would then be 1100000 which is still greater than 2000 ...
> 
> Even,
> 
> Ugg.   OK, I now remember this being one of the reasons I'm not in
> favor of a 1.10 release.  I'm not too fond of redefining GDAL_VERSION_NUM's
> layout.  I wonder if this would cause any surprising problems.

I can't imagine any particular problem this would cause. I've tried to think 
at crazy stuff, like dividing GDAL_VERSION_NUM by 100.0, and do for example
#if GDAL_VERSION_NUM / 100.0 >= 1.8

But floating point in preprocessing is not allowed, and even if they did that, 
this would still work with the new way of computation GDAL_VERSION_NUM. The 
only constraint I see is that the version numbers for the next versions are 
greater than the ones of previous releases.

I've checked in QGIS and MapServer, and they both do stuff like :
#if defined(GDAL_VERSION_NUM) && GDAL_VERSION_NUM >= 1600

> 
> Blech