[GiNaC-devel] versions and branches

Jens Vollinga jensv at nikhef.nl
Fri Dec 10 12:43:52 CET 2010


Hi Alexei,

Am 10.12.2010 11:41, schrieb Alexei Sheplyakov:
>> * Distros don't like library soname changes. Let's stick to the
>> current one as long as possible.
>
> I agree. However, I was discussing a different problem. As of now we have
> a branch per SONAME. I don't think it's a good idea (does this really help
> packagers? I really doubt it), it just imposes additional maintenance work
> (like cherry-picking *all* patches from one branch to another). Therefore
> I propose to get rid of those branches, and indicate binary-incompatible
> changes in a standard way, that is, by updating the SONAME (or whatever it
> is on $OS). This doesn't mean we should break ABI as often as we can.
> Any objections?

okay, now I start to understand your proposal.

I try to give a better example than last time for what I think is a 
disadvantage:

Up to now somebody can pull or checkout ginac_1-5 and will always get 
the latest ABI-compatible code for 1.5.x. If we merge, 1.5.x will 
suddenly be on master, and one would have to monitor any commits on 
master then for their relevance to 1.5.x.

Then somebody commits an ABI-breaking patch and we would have to 
recreate another branch for the "new" 1.5.x code. How should we name 
that? Something like ginac_1-5-VI-The_Return_of_the_ABI? We would have 
two git branches for one ABI branch. That is what I think is ugly.

Now to your proposal. It is hard to come up with a real objection. :-) I 
don't like the thing I described above happening, but on the other hand 
I also appreciate the benefits your idea would deliver and so I don't 
think it is not a strong argument against your proposal.

But until your latest email I didn't fully understand your idea (well, 
you didn't explain in detail until now). I thought you would like to 
merge master and ginac_1-5 just for once, because for some historical 
coincidence they have grown compatible again. Do I understand correctly 
that we should only commit to master from now on and not create any new 
branches? Would that mean that we don't fix bugs in older ABI-branches 
anymore, i.e. leave it to say the debian people to backport bug fixes?

Regards,
Jens


More information about the GiNaC-devel mailing list