On Sun, Dec 24 2017, Eric Wong jotted: [Removed Petr Baudis <pasky@xxxxxxx> from CC, his suse.cz E-Mail address is bouncing] > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: >> On Sun, Dec 24 2017, Jeff King jotted: >> > As far as this actual perl change goes, I don't have a strong opinion. I >> > agree it would be nice to eventually move forward, and your reasoning >> > about what constitutes "old" seems sane. But we also don't write much >> > perl in this project these days, and I don't see a lack of modern perl >> > features causing a lot of headaches. > > Agreed. > >> Yes, unlike with the curl patches it's not a big PITA to maintain >> compatibility with 5.8, it would just be easier to write new code & >> maintain old code and not have to be on guard about not using features >> one takes for grantend, and maintain compatibility with 5.8 versions of >> core modules. > > As one of the more frequent Perl users here (even outside of > git.git), I never considered using 5.10+ features at all until > now. Maybe 5.8 compatibility is just too ingrained into me and > much of the stuff I work on is old and ancient(*). > > That said, reading perl5100delta does reveal features such as > defined-or and given/when that I might find useful; but I'm also > not going to replace existing code to use new features unless > there is a clear improvement. > > If there's new code people are developing using 5.10; I would > not object at all. Otherwise, I don't see compatibility with > 5.8 hurts more than it helps. Aside from whatever we do here, I don't think this would be a good idea & would introduce a lot of confusion for packagers, e.g. requiring one version of OpenSSL for hashing, but another one for "imap-send", or one version of curl for "push", and another for "imap-send". 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. > 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). 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. 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). 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]. 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)
