On 15/09/10 16:03, Julian Taylor wrote: > On Wed, 2010-09-15 at 15:07 +0200, Mateusz Loskot wrote: >> On 15/09/10 15:04, Denis Arnaud wrote: >>> 2010/9/15 Mateusz Loskot <[email protected] <mailto:[email protected]>> >>> >>> 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? >>> >>> >>> I agree for all those three points. >> >> Good. >> >> I'd like to wait for comments from Julian and Artyom and anyone else >> who is interested in this aspect. >> Let's make it based on a democratic decision process, so all who >> participate in it will be happy :-) >> >> Best regards, > > Having a more complex soversion is not recommend, but also not > forbidden, by debian policy.
Right, though I'm personally voting for as simple as possible (usable) policy. > So as long as you will always break api/abi on minor updates and never > on patch releases its fine with me. Yes, I think so. I can hardly imagine new features or new backends without breaking binary compatibility, but bug fixes should never break. If bug fixes break it, then we can issue minor release instead of patch release. > Please inform me when the decision is final, so I can update the dynamic > loading patch in the tracker appropriately. Sure. Thanks! 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
