Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > I think for any given external dependency of git.git it makes sense to > just pick a version, not say that this script requires perl so-and-so, > this one python so-and-so, or curl/openssl so-and-so etc. Agreed. Any version support changes should be tree-wide. > On Sun, Dec 24 2017, Eric Wong jotted: > > Maybe we change our docs to say we welcome 5.10 features for new > > code, but I'm against changing things for the sake of change. > > I should have mentioned this in the commit message, but for me it's > mainly that whenever I patch the Git perl code there's no easy way to > test if it works on a currently supported release, 5.8.* doesn't even > build anymore on a modern compiler without monkeypatching with > Devel::PatchPerl (and then only some subreleases). Fair enough, I haven't run 5.8 in a while, either. One concern I have is it makes reviewing more difficult as the language gets bigger and (even more) unfamiliar constructs pop up. This is probably more important for git as most of us are not dedicated Perl hackers. What mostly bugs me about this is going from: "we'll accept patches to keep your old system working" to: "your software is too old, upgrade or go away" > I think it's reasonable for us, in general, to at some point pass the > buck in maintaining dependencies to people who want to still build on > ancient versions. And not just for perl, but e.g. curl too, which is > something I commented on at some length in <874ltg2tvo.fsf@xxxxxxxxx> > (https://public-inbox.org/git/874ltg2tvo.fsf@xxxxxxxxx/). I.e. if you > need to really build the latest git on RHEL 5 with all bells & whistles > you also build perl. I don't disagree; but curl is different animal in that it was a maintenance burden for us. > It's not just change for the sake of change, there's a high cognitive > overhead in trying to write code against the last 15 years of some > software as opposed to "just" 10 years (which is already bad enough). Heh, I was making the same point for staying with older versions since it's less cognitive overhead for me (and presumably others) to use a smaller featureset. > Of course any one change isn't going to be what makes it or breaks it, > so it's hard to make the argument in terms of "I must use this new > feature here". But if that was the standard we were applying we'd still > be supporting perl 5.6[1]. Right, if there's a compelling case to depend on 5.10 then I'm all for it. I don't think we've hit a breaking point like we did with 5.8, yet. > 1. If it hadn't turned out that it was broken for years because of using > a new feature, see d48b284183 ("perl: bump the required Perl version > to 5.8 from 5.6.[21]", 2010-09-24)
