On 14/09/10 14:32, Denis Arnaud wrote: > 2010/9/14 Julian Taylor wrote: >> >> I would stick with a unrelated number increased on change as almost >> every other library out there. > > > 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).
This is exactly my point. I'd like to keep this procedure as simple yet automatic as possible. I have added soci_version() macro. IMHO, it would be best if SOVERSION is derived from release version, so SOCI bumps version in one place in the root CMakeLists.txt soci_version(3.2.0) and SOVERSION is set automagically. Assuming SOVERSION can be calculated, it's more important to me to decide about consistent release versioning. For instance, it could be managed this way: - bug fixes bump only patch level (micro version number), never bumps SOVERSION - changes to existing core and backends that touch API or ABI only bump minor level only, bumps SOVERSION - addition to the SOCI system as a whole like new backend, new data mapping (e.g. high precision artithmetic numbers) would bump major version number, bumps SOVERSION as well. Makes sense at all? 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
