Hi, looks like I could do a 1.5.9 release this weekend. Any objections? Regards, Jens
Hi, Jens, On Thu, Dec 09, 2010 at 09:06:53PM +0100, Jens Vollinga wrote:
looks like I could do a 1.5.9 release this weekend. Any objections?
I have a few patches pending (msvc support and few others). Also I'd like to merge the master branch with 1.5. It looks like having two branches is of no advantage, instead it imposes maintenance overhead (also, some patches get lost). Best regards, Alexei
Hi Alexei, Am 09.12.2010 21:51, schrieb Alexei Sheplyakov:
I have a few patches pending (msvc support and few others).
okay, I'll wait.
Also I'd like to merge the master branch with 1.5. It looks like having two branches is of no advantage, instead it imposes maintenance overhead (also, some patches get lost).
I don't understand. "no advantage" is not the point, the two branches are just not compatible, so having two branches is just a necessity. But, of course, we could leave the 1.5 branch behind and release the master as 1.6.0. Is this your plan? Regards, Jens
Hi again, On Thu, Dec 09, 2010 at 10:06:51PM +0100, Jens Vollinga wrote:
Also I'd like to merge the master branch with 1.5. It looks like having two branches is of no advantage, instead it imposes maintenance overhead (also, some patches get lost).
I don't understand. "no advantage" is not the point, the two branches are just not compatible,
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 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).
so having two branches is just a necessity.
I don't agree (see the explanation above). Best regards, Alexei
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
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/>
Hello! On Fri, Dec 10, 2010 at 08:24:55AM +0100, Richard B. Kreckel wrote:
* 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? Best regards, Alexei
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
Hi Jens, On Fri, Dec 10, 2010 at 12:43:52PM +0100, Jens Vollinga wrote:
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.
This is not completely true, sometimes ABI get broken even in "stable" branch(es), sometimes the code won't even compile (see e.g. the commit eaf81b311569), etc.
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.
No, we won't create any branches just because of the ABI changes. Instead we update the version info (ginac_lt_current, ginac_lt_age, ginac_lt_revision) *just before making the release*, and that's it. This doesn't mean we'll break ABI at whim.
Do I understand correctly that we should only commit to master from now on and not create any new branches?
Yes, almost. We might create (short-living) branches for developing $some_feature (a.k.a. `topic branches'), and merge them into master again, when $that_feature is ready for release (example: msvc.support branch). Again, this doesn't mean we should create such a branch for every single feature.
Would that mean that we don't fix bugs in older ABI-branches anymore,
We don't really have manpower to do this anyway, do we?
i.e. leave it to say the debian people to backport bug fixes?
We'd better tell them to upgrade to the newest version. Best regards, Alexei
Hi Alexei, Am 10.12.2010 14:42, schrieb Alexei Sheplyakov:
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.
at that point I was still arguing against the proposal as I had it understood before explained it in detail, but anyway ...
No, we won't create any branches just because of the ABI changes. Instead we update the version info (ginac_lt_current, ginac_lt_age, ginac_lt_revision) *just before making the release*, and that's it. This doesn't mean we'll break ABI at whim.
okay, that's clear now. I support your proposal. It makes sense. But probably we should announce this policy change somehow. I could do this in the next release announcement email. Now, technically, do you merge and we (richy or myself) pull, or should we merge, or ... ? Who is leading the revolution? Regards, Jens
Hi again, On Fri, Dec 10, 2010 at 03:25:16PM +0100, Jens Vollinga wrote:
But probably we should announce this policy change somehow. I could do this in the next release announcement email.
I think it's a good idea.
Now, technically, do you merge and we (richy or myself) pull, or should we merge, or ... ? Who is leading the revolution?
Please pull from git://github.com/AlexeiSheplyakov/GiNaC.tmp.git master ... and wait for more pull requests :) Best regards, Alexei
Hi all! On 12/10/2010 06:26 PM, Alexei Sheplyakov wrote:
Please pull from
git://github.com/AlexeiSheplyakov/GiNaC.tmp.git master
... and wait for more pull requests :)
Alexei: Jens asked me to do the sync with your repository in order to prepare for an upcoming release. I just pushed it all and am now unaware of anything missing. Please complain, if I overlooked something. -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hi! On 12/10/2010 03:25 PM, Jens Vollinga wrote:
okay, that's clear now. I support your proposal. It makes sense. But probably we should announce this policy change somehow. I could do this in the next release announcement email.
Also, the Git bullet at <http://www.ginac.de/Download.html> may have to be modified, then. Bye! -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hi! On 12/10/2010 11:41 AM, Alexei Sheplyakov wrote:
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),
Of course not. Ideally, distributors don't want to care about what's going on behind upstream releases. The idea was to be able to collect more dangerous and ABI-breaking changes on master until it was ripe for release. Bye! -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hello, On Thu, Dec 09, 2010 at 11:05:18PM +0100, 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.
Actually we don't. If something (bugfix or a new feature) introduces the ABI change all we need is to bump the library version info (as described in http://www.gnu.org/software/libtool/manual/libtool.html#Versioning), and put some prominent note into the ChangeLog.
Merge eventually later. We might revert the patch because we found a better solution, and therefore have to branch again.
No, we just revert the bad patch and apply the new one.
As a result our branch tags or version numbers would not only rise much faster (no problem, actually, unless distro maintainers feel annoyed),
No, they won't, if we update library version properly (that is, before making a new release, not immediately after breaking the ABI).
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.
In fact there's no mapping between the package release number and the library interface version. They are absolutely different, and there's no way to tie them. Best regards, Alexei
Hi! On 12/09/2010 10:06 PM, Jens Vollinga wrote:
Also I'd like to merge the master branch with 1.5. It looks like having two branches is of no advantage, instead it imposes maintenance overhead (also, some patches get lost).
I don't understand. "no advantage" is not the point, the two branches are just not compatible, so having two branches is just a necessity.
Surprise: The ABI of master is still compatible to the one released in 1.5.0. Bye! -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
participants (3)
-
Alexei Sheplyakov
-
Jens Vollinga
-
Richard B. Kreckel