Florian Forster wrote:
> Hi again,
>
> On Tue, Mar 17, 2009 at 05:09:15PM +0100, Markus Hoenicka wrote:
>> I'm not going to do that, as discussed before on this list. In brief,
>> we forgot to update the libtool interface version info in the past. In
>> the worst case your suggestion will cause us to forget to uptate the
>> interface version *and* the library version :-(
>
> updating the ABI version is basically not possible to do automatically,
> that's true. Updating the defines suggested automatically would be easy,
> though:
> -- 8< (configure.{ac,in}) --
> LIBDBI_VERSION_MAJOR=`echo $PACKAGE_VERSION | cut -d'.' -f1`
> LIBDBI_VERSION_MINOR=`echo $PACKAGE_VERSION | cut -d'.' -f2`
> LIBDBI_VERSION_PATCH=`echo $PACKAGE_VERSION | cut -d'.' -f3`
> AC_SUBST(LIBDBI_VERSION_MAJOR)
> AC_SUBST(LIBDBI_VERSION_MINOR)
> AC_SUBST(LIBDBI_VERSION_PATCH)
> -- >8 --
>
> -- 8< (dbi_version.h.in) --
> #define LIBDBI_VERSION_MAJOR @LIBDBI_VERSION_MAJOR@
> #define LIBDBI_VERSION_MINOR @LIBDBI_VERSION_MINOR@
> #define LIBDBI_VERSION_PATCH @LIBDBI_VERSION_PATCH@
> #define LIBDBI_VERSION_STRING "@libdbi_version_ma...@." \
> "@libdbi_version_mi...@.@LIBDBI_VERSION_PATCH@"
#define LIBDBI_VERSION ((LIBDBI_VERSION_MAJOR * 10000) + \
(LIBDBI_VERSION_MINOR * 100) + LIBDBI_VERSION_PATCH)
Noone wants to use 3 #ifdef's if they can get away with a
single #if ;-)
>
>> But instead of abusing the library version as an interface version,
>> I'd like to use the interface version as the library version.
>
> Yeah, that should work, too..
>
>> I've never understood why a library needs a version number that is
>> different from the interface number.
>
> Well, I usually think of the API as being whatever is *documented*. For
> example, changing the order of members in a struct would, in my opinion,
> not break API compatibility but would break ABI compatibility. As a
> developer, i. e. an ``API user'', this would not be of importance to me.
> Or course, this is a trivial example. I'm sure you can think of some
> more practical examples, a bitfield being widened or a struct being
> changed but the API only documents macros to access the struct or
> something.
>
It can be uglier than that. If you use the long datatype and and change
it to an int later, you're breaking the ABI on 64-bit platforms but not
on 32-bit ones.
> Personally, I like the package version to make a statement towards API
> compatibility, because I mainly use libraries from the viewpoint of a
> developer. The system I'm usually using is the following:
> - The major version increases upon backwards-incompatible API changes.
> - The minor version increases upon backwards-compatible API changes,
> usually additions.
> - The patch version is increased if the API has not been changed at all.
>
> The ``major'' number of this schema would roughly equal `current - age'.
>
>> What changes would justify increasing LIBDBI_MAJOR without affecting
>> LIBDBI_LIB_CURRENT?
>
> If you use `current' as major version, it is increased whenever anything
> in the API changes (assuming you don't start doing extensive
> preprocessor trickery to keep the functions as they are ;)
You can use versioned symbols for that. I don't know if that's considered
preprocessor trickery (as it's actually linker trickery). Almost all the
actual preprocessor trickery I can think of breaks the ABI and requires a
bump of the .so-version at the very least.
> - whether
> backwards compatible or not. So my point is the other way around: The
> `current' version must be increased when I would keep the `major'
> version as is.
>
>> Why would changes that require a new interface be reflected by an
>> increase of LIBDBI_MINOR instead of LIBDBI_MAJOR?
>
> In the schema above: When a function is *added*. In that case:
> - current would be increased.
> - revision would be reset to zero.
> - age would be increased.
>
> - major would stay the same.
> - minor would be increased.
> - patch would be reset to zero.
>
That's how 99% of the library developing world does it. When in doubt,
follow the path of least surprise ;-)
--
Andreas Ericsson andreas.erics...@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
libdbi-devel mailing list
libdbi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-devel
