On 14/09/10 21:45, Julian Taylor wrote: > 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.
The point is that SOCI is multi-platform and in some platforms there is no concept of SOVERSION. Thus, I'd like to not to expose SOVERSION as a part of maintenance interface, but hide it in internal details of CMake configuration. Meaning, calculate it automatically. Does anyone know if and how SOVERSION is managed in Boost? Perhaps adopting well tested scheme would be easiest. > 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. I'd like to promise users with the following: - that patch level changes never breaks ABI. - major and minor version may or, rather, will break ABI. Then, as I've mentioned, it would be easy to derive SOVERSION policy: - patch level never bumps SOVERSION - minor or major changes always bump > 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. Isn't it possible to safely assume, bug fix in API touches ABI as well? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ------------------------------------------------------------------------------ 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
