+1 Tamas
2012/11/9 Even Rouault <even.roua...@mines-paris.org> > 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 >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev