Hi! On 12/09/2010 11:05 PM, 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. Merge eventually later. We might revert the patch because we found a better solution, and therefore have to branch again. As a result our branch tags or version numbers would not only rise much faster (no problem, actually, unless distro maintainers feel annoyed), 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. Rising version numbers would no longer signify a real progress (don't as for a definition! ;-) ) but just documents in the branch "bumps" along the master. This is an disadvantage to me.
I have no strong opinion yet whether the advantage you outlined outweighs the aforementioned disadvantage. I'd like to hear more opinions or arguments.
Putting my distributor's hat on: * Distros should steer clear of stuff from unreleased branches. If they fail to do so they cannot blame upstream for anything. * Distros don't like library soname changes. Let's stick to the current one as long as possible. * If, at some point, 14-0 restores compatibility to 11-2 or the other way around, that would just be seen as an uninteresting quirk. Bye! -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>