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. So as long as you will always break api/abi on minor updates and never on patch releases its fine with me. Please inform me when the decision is final, so I can update the dynamic loading patch in the tracker appropriately.
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ 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
