On Tue, 2010-09-14 at 14:32 +0200, Denis Arnaud wrote: > 2010/9/14 Julian Taylor <[email protected]>
> > > It's just that it's then harder to maintain: who will decide when to > bump the soname version? When? How? Should there be a procedure for > that? etc. In contrast, the major.minor scheme is easier to maintain, > since it is automatic (as it follows the version numbering scheme). > > But, really, I do not care that much, beyond the maintenance issue, > about which soname version scheme will be adopted (and as I'm not > really a maintainer, it's not really my problem either). Provided > there is a consistent soname version scheme, I'll be happy to continue > packaging Soci :) > > D Well if you do not want to think about if your change broke the api you can just increase the soname version in addition to every version number change. The maintenance overhead is increasing one additional number on the same line. I think that is manageable. Having only one number is clear in the sense of what that number represents: The abi/api version. There is no major, minor or patch in an api version, either it breaks compatibility or not. The drawback is the possibility that the version bump can be forgotten if one is careless with a new release. The automatic schema on the other hand has the drawback that api changes must increase the minor number even when they only fix a bug and you unnecessarily increase the library version even when you know you don't need to.
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________ Soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
