[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