[Gdal-dev] Radical OGR Update

Alessandro Amici alexamici at fastwebnet.it
Thu Feb 19 16:32:54 EST 2004


Daniel, Frank,

On Thursday 19 February 2004 20:06, Daniel Morissette wrote:

[nod and snip]

> Also, I would like to suggest that you stop being cheap on version
> numbers ;) ... instead of going with 1.1.x when new features or new
> drivers are added, I think you should go 1.2, 1.3, 1.4 and use the last
> digit of the version numbers only for bug fix releases (after creating a
> stable branch in CVS).  That's how most projects seem to work, that also
> how we do things with MapServer and that works very well.

the libtool way to build the soversion seems really neat to me (well, it might 
be that i just spent too much time into 'info libtool', thou ;) and can be 
easily used to get meaningful release numbers for a library.

versions are something like 'major.minor.revision' and thinking in terms of 
exported interfaces you need to follow the following rules:

- whenever you drop any exported interface bump the major number and reset the 
minor number to zero; (any non-backward compatible change trigger this rule)

- whenever you add an interface (and don't drop any old interface), bump the 
minor number

- whenever you do a bug-fix only release (without _any_ interface change), 
bump the revision number.

note that an interface change counts as an added interface plus a dropped one.


this way the version number has a very clear meaning:
new revision == bugs have been fixed, go grab it and install it.
new minor == new features are available, source compatibility _and_ binary 
compatibility for existing applications are garanteed.
new major == beware! some old (ugly) interface have been dropped. binary and 
possibly source compatibility have been broken, you need to audit and fix 
your code. at the very minimum your apps need to be recompiled (well relinked 
to be precise).

finally, the difference between revision and minor numbers lies in the binary 
compatibility with older versions. applications built against a libray with 
higher revision numbers (x.y.z+1) are always binary compatible with libraries 
with older revisions (x.y.z). this is not always true for minor numbers: if i 
use in my apps an interface that is new in x.y.z, they will not work on a 
system with version x.y-1.w of the library.


using this scheme gdal-1.1.9 whould probably be versioned something like 1.9.0 
and the upcoming gdal-1.2.0 would be 2.0.0 due to the changes related to the 
soversion.


enough rambling, good night,
alessandro



More information about the Gdal-dev mailing list