On Thu, Aug 10, 2017 at 03:17:06PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > On Thu, Aug 10, 2017 at 11:36:41AM +0200, Johannes Schindelin wrote: > > > >> Hopefully I had better luck expressing my concerns this time? > > > > I understand your argument much better now. I'm still not sure I agree. > > > > -Peff > > I do not think "there are a dozen #ifdefs and I don't know whether > they still work. I don't know whether anybody (who most likely has > better things to do than read the Git mailing list) is still using > those. So let's just remove them." was why you were suggesting to > clean up the (apparent) support of older curl in the code, though. > > Isn't the reason why your series simplifies these #ifdefs away > because we by accident started using some features that require a > version that is even newer than any of these #ifdef's try to cater > to and yet nobody complained? That is a lot more similar to the > removal of rsync transport that happened in a not so distant past, > where the reason for removal was "We have been shipping code that > couldn't have possibly worked for some time and nobody complained > ---we know nobody is depending on it." I think there are two questions to be asked, and their answers come from different lines of reasoning. The first is "should we eventually drop support for antiquated versions of dependencies?". And the argument in favor is the one I was making here: besides lowering maintenance cost, it is more honest to our users about what to expect[1]. The second is "how far back should we keep support?". And there are two lines of thought there. One is to do it by date and what dependencies are in long-term OS releases, and then compare that to the benefit. Requiring curl 7.11.1 still keeps us working back to rhel4, which was already end-of-lifed completely after a 12 year run. Bumping to 7.16.0 drops rhel4 and rhel5, the latter of which is in its final "barely supported" phase after 10 years. But it gives us a bit more bang for our buck by making CURL_MULTI uconditional[2]. Requiring 7.19.4 actually doesn't drop any more rhel releases. So by that metric, we might as well go there. And the second line of thought is: it was already broken and nobody reported it or offered up a fix. And that's where the "similar to rsync" thing comes in. Though in this case we do have some evidence that people (at least Tom) was patching and distributing behind the scenes. And our breakage period was much shorter (since v2.12.0, but that's only months or so). -Peff
