On 13/09/10 16:26, Julian Taylor wrote: > 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.
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) etc. I have to admit, I never respected SOVERSION scheme myself, so now I need to learn over my ignorance :-) I'm open to suggestions to make the version numbering as simple as possible, not involving any fancy calculations and as reliable as it is needed. 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
