> > OK, so you're suggesting to maintain SOCI version and SOVERSION > separately what will mean in practice that SOVERSION is not reflected in > any way in SOCI version. For example, following versions are possible: > > SOCI 3.1.0 with SOVERSION 5 > SOCI 3.5.0 with SOVERSION 5 (no api change) > SOCI 3.5.1 with SOVERSION 6 (patch release with api change) > SOCI 3.6.0 with SOVERSION 7 (minor release with api change) > SOCI 4.0.0 with SOVERSION 7 (major relase, no api change happened) >
Please note, SOVERSION is not about API it is about ABI. Even if you hadn't changed anything in the API but added some private member or removed from the public class: ABI had broken as sizeof class had changes. AFAIK soci does not put too much effort in keeping ABI stable (correct me if I wrong) in such case you probably should update SOVERSION almost any release. This is very good reading: <http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++> Keeping ABI is quite hard in C++, so if you don't sure it is better to increase SOVERSION each release. Artyom ------------------------------------------------------------------------------ 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
