[GiNaC-devel] release

Jens Vollinga jensv at nikhef.nl
Thu Dec 9 23:05:18 CET 2010


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


More information about the GiNaC-devel mailing list