I would also recommend not to associate the SOVERSION with the major version number. You may be forced to break the api for a minor release or even a patch too. It should just be some generic number incremented on every change.
And the soname created by cmake (e.g. libsoci_sqlite3.so.SOVERSION) should be the library name used for the dynamic loading in backend_loader.cpp Currently it does not have the SOVERSION attached so programs may break when the api changes and a new version is installed next to the old one. I can probably provide a patch for this later. On 9/13/10, Denis Arnaud <[email protected]> wrote: > 2010/9/13 Mateusz Loskot <[email protected]> > >> I have decided to go for simple approach: >> SOCI_VERSION = MAJOR.MINOR.PATCH >> SOCI_SOVERSION = MAJOR >> > > That's fine, I believe. > > Thinking of API/ABI versioning and given amount of changes that have >> happened in SOCI, I've started to think that the upcoming >> release should be numbered 4.0.0 rather than 3.1.0. >> > > What about 3.5.0? There seems to be similar schemes in gcc, KDE and MySQL: > 3.5.0 tells that there has been a leap forward, not necessarily > backward-compatible with previous versions, and that it prepares a future > version 4.0.0. > > Regards > > D > ------------------------------------------------------------------------------ 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
