On 30/09/10 22:18, Julian Taylor wrote: > On Wed, 2010-09-29 at 23:50 +0100, Mateusz Loskot wrote: > >> I'm not KDE, but GNOME user and I think both desktops use the smae scheme: >> >> http://live.gnome.org/InterfaceSpecification#Library_Versioning >> >> Applying to SOCI, we would get the following 3 simple rules manually >> maintained by the team and automatically executed by CMake: >> >> MAJOR - Incremented when the interfaces are changed in ways that are ABI >> incompatible. When incremented MINOR and PATCH become 0. >> >> MINOR - Incremented when interfaces are added or deprecated. In other >> words, only ABI compatible interfaces changes are allowed. When >> incremented PATCH becomes 0. >> >> PATCH - Incremented when only bugs that do not affect interfaces are fixed. > > > This schema is for very mature libraries with very stable api/abi. > If this is not the case you may be forced to bump the major version more > often that you'd like to. > If you consider soci to be in that stage it is fine.
Julian, I don't think it's possible to asses maturity of project accurately, in terms of its API/ABI stability. Thus, not possible to predict version number changes. Also, I'd not be worried about running out of numbers. >From my point of view, it's more important to have defined clear, simple and constant scheme of version numbering. If there are no alternative proposals, I'd like to stick to this scheme. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.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
