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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
