Hello, On Thu, Dec 09, 2010 at 11:05:18PM +0100, Jens Vollinga wrote:
Thinking about the future this might lead to some odd (to me!) branching behaviour (I don't know whether odd==bad, though). As soon as someone makes a commit that introduces "incompatibility" we would need to branch.
Actually we don't. If something (bugfix or a new feature) introduces the ABI change all we need is to bump the library version info (as described in http://www.gnu.org/software/libtool/manual/libtool.html#Versioning), and put some prominent note into the ChangeLog.
Merge eventually later. We might revert the patch because we found a better solution, and therefore have to branch again.
No, we just revert the bad patch and apply the new one.
As a result our branch tags or version numbers would not only rise much faster (no problem, actually, unless distro maintainers feel annoyed),
No, they won't, if we update library version properly (that is, before making a new release, not immediately after breaking the ABI).
but we could for example have a version 11-2 which is binary compatible to a version 14-0 but not to versions 12-x or 13-x. The mapping between repo branches and version branches becomes non-trivial.
In fact there's no mapping between the package release number and the library interface version. They are absolutely different, and there's no way to tie them. Best regards, Alexei