[gdal-dev] Motion: Release next major GDAL version as GDAL/OGR 1.10

Daniel Morissette dmorissette at mapgears.com
Mon Nov 12 13:27:02 PST 2012


+1 Daniel


It took me a while to respond because initially I was worried about the 
potential impact on released application code calling GDAL (from other 
projects/products). Unless I'm mistaken it seems to me that there will 
be no impact on pre-1.10 application code that used to test for things 
like GDAL_VERSION_NUM >= 1800 (for instance). This code will continue to 
work, and only tests for GDAL 1.10/2.0 and greater will need to be fixed 
to use the new macro, which means a minimal impact limited to recent 
code which was based on non-released GDAL features anyway.



On 12-11-09 3:10 PM, Even Rouault wrote:
> Motion: The next major GDAL version released from trunk will be called
> GDAL/OGR 1.10.
>
> To take into account 2-figure numbers in the components of the version number,
> the GDAL_VERSION_NUM macro will be changed accordingly as :
>
> #  define GDAL_VERSION_NUM
> (GDAL_VERSION_MAJOR*1000000+GDAL_VERSION_MINOR*10000+GDAL_VERSION_REV*100+GDAL_VERSION_BUILD)
>
> A new macro will be added so that users don't have to do all the above
> multiplications :
>
> #define GDAL_COMPUTE_VERSION(maj,min,rev)
> (maj*1000000+min*10000+rev*100)
>
> (Note: as raised by Mateusz, I've dropped the 'build' argument in the macro,
> since it has never been used in the past and it is unlikely code would depend
> on that)
>
> ----
>
> Hi,
>
> Not surprisingly when it is related to preferences on version numbering, the
> previous discussion thread has not lead to a clear consensus on the topic, but
> we need to make a decision soon so that users can anticipate the adaptations
> needed in their code.
>
> 1.10 seems the more logical option to me, even if that implies changing the
> way we compute GDAL_VERSION_NUM, which I don't anticipate to cause problems to
> existing code. There are also a few existing documentation pages in drivers or
> utilities that mention GDAL 2.0 that will need to be changed, but I'll take
> care of this if the motion is approved (some sed magic should do this).
>
> +1 Even
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>


-- 
Daniel Morissette
http://www.mapgears.com/
Provider of Professional MapServer Support since 2000



More information about the gdal-dev mailing list