alexei.sheplyakov at gmail.com
Fri Dec 10 11:22:04 CET 2010
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
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
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
More information about the GiNaC-devel