Hi Alexei, Am 09.12.2010 22:21, schrieb Alexei Sheplyakov:
Well, most of commits in 1.5 and master are actually the same (the patches get applied to master and cherry-picked to 1.5 or vice a versa).
git diff origin/ginac_1-5..origin/master
okay ... since when? And, always? (pleeeeeease don't answer these questions! Like with the compatibility statement in my last mail I was mainly thinking about the ensuing issue I will explain below. I first tried to understand your proposal by asking!)
shows that only ChangeLog and the version info in configure.ac differ. So we have two branches with the same history (modulo patch ordering). In my opinion this makes very little sense, so I propose to merge those branches. Alternatively we can abandon the 1.5 branch, and continue development on master, that is, *without* creating the separate branch for 1.6 (and any future versions).
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. I am always in favor of the better solution as soon as I recognize it as such. ;-) Regards, Jens