git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC] dropping support for ancient versions of curl

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Apr 7, 2017, 11:18 UTC
Message-ID
<alpine.DEB.2.20.1704071257560.4268@virtualbox>
In-Reply-To
<20170406092942.ow4mvce5miyzbgld@sigill.intra.peff.net>
Hi Peff,
On Thu, 6 Apr 2017, Jeff King wrote:
> And it's not like people on ancient mission-critical systems get cut
> off. They can still run the version of Git they were running when their
> OS went out of support.
You keep baiting me, so I'll bite, after resisting the urge for so long.

Let me share a little story of my own. So that this is not some academic, theoretical wanking off, but something very tangible, very concrete, and something very hard to handwave away.

As you know, in my previous job I was working as a scientist. Part of my job was to support other scientists e.g. when they were using that really big, really expensive, really advanced and super cool microscope. The "really advanced" part only applied to the hardware, though, they were running a super old CentOS, and everything was clamped down pretty good (as many microscope vendors are wont to do), so there was no way to upgrade the OS (I do not recall whether the drivers were only available for this particular version of CentOS, but it would make sense, wouldn't it, now, as microscope vendors are much more of experts in microscope hardware than in anything vaguely related to software, even if they like to pretend to be experts in both).

I did have access to gcc, though. And I did have to get Git working to be able to install and develop additional software on that machine. It did take me a while to get things to compile because of ancient libraries being installed on that machine. Since only trusted people were allowed to use that machine, security on that box was not really an issue. It did make work for my colleagues substantially easier once I could develop on that machine, using Git.

Just imagine how thankful I was that support for these old library versions was almost working, still, and the one bigger problem I had was easily solved by a patch that a quick web search found!

This. This is the impact of supporting older library versions, even if they are long EOL.

Do not get me wrong: I am all for dropping support that is a huge maintenance burden. You probably do not know the full back story, but let me tell you what a relief it was to drop Windows XP support in Git for Windows (and the Cygwin developers can sing several epic, Lord of the Rings sized war songs about that, too).

At the same time, I want us to do better than all those maintainers out there who drop backwards-compatibility just for the heck of it, not because it would be a huge maintenance burden. "Everybody should upgrade, anyway" is usually the naive excuse for not knowing why users are often unable to upgrade.

Git is incredibly popular, and part of that is due to us being inclusive and open and supporting a wide range of platforms. Yes, we can always do a better job, that is true. We are also doing pretty well, though, and I think that part of the reason is that we weigh carefully the maintenance cost against the benefit of our users. Tiny "cleanup" patches that fail to improve the maintenance burden substantially, and that also make users' lives harder, are rightfully rejected. A little harder work from us maintainers goes a long way to make a lot of users a lot happier.

My former self in my former life as a scientist is very thankful for the consideration that goes into each and every "should we drop supporting XYZ?" decision.

Very, very thankful.

Ciao, Dscho

Previous: Jeff KingNext: Jeff King
Message 43 of 48 in “[RFC] dropping support for ancient versions of curl”
  1. Jeff KingApr 4, 2017
  2. Jeff KingApr 4, 2017
  3. Jessie HernandezApr 4, 2017
  4. Ævar Arnfjörð BjarmasonApr 4, 2017
  5. Jeff KingApr 4, 2017
  6. Ævar Arnfjörð BjarmasonApr 4, 2017
  7. Johannes SchindelinApr 4, 2017
  8. Ævar Arnfjörð BjarmasonApr 4, 2017
  9. Brandon WilliamsApr 4, 2017
  10. Johannes SchindelinApr 4, 2017
  11. Brandon WilliamsApr 4, 2017
  12. Stefan BellerApr 4, 2017
  13. Johannes SchindelinApr 5, 2017
  14. Jeff KingApr 5, 2017
  15. Jeff KingApr 4, 2017
  16. Frank GevaertsApr 4, 2017
  17. Tom G. ChristensenApr 5, 2017
  18. Ævar Arnfjörð BjarmasonApr 5, 2017
  19. 0/7 Patches to support older RHEL releasesTom G. Christensen, Apr 5, 2017
  20. 3/7 Allow svnrdump_sim.py to be used with Python 2.2Tom G. Christensen, Apr 5, 2017
  21. Ævar Arnfjörð BjarmasonApr 5, 2017
  22. Tom G. ChristensenApr 5, 2017
  23. 1/7 Make NO_PERL_MAKEMAKER behave more like ExtUtils::MakeMakerTom G. Christensen, Apr 5, 2017
  24. 4/7 Handle missing HTTP_CONNECTCODE in curl < 7.10.7Tom G. Christensen, Apr 5, 2017
  25. Ævar Arnfjörð BjarmasonApr 5, 2017
  26. Franke, KnutApr 5, 2017
  27. 2/7 Install man pages when NO_PERL_MAKEMAKER is usedTom G. Christensen, Apr 5, 2017
  28. 5/7 Add support for gnupg < 1.4Tom G. Christensen, Apr 5, 2017
  29. Ævar Arnfjörð BjarmasonApr 5, 2017
  30. Junio C HamanoApr 13, 2017
  31. Ævar Arnfjörð BjarmasonApr 13, 2017
  32. 6/7 Handle missing CURLINFO_SSL_DATA_{IN,OUT}Tom G. Christensen, Apr 5, 2017
  33. Ævar Arnfjörð BjarmasonApr 5, 2017
  34. 7/7 Do not use curl_easy_strerror with curl < 7.12.0Tom G. Christensen, Apr 5, 2017
  35. Ævar Arnfjörð BjarmasonApr 5, 2017
  36. Jeff KingApr 6, 2017
  37. Junio C HamanoApr 13, 2017
  38. Jacob KellerApr 13, 2017
  39. Tom G. ChristensenApr 5, 2017
  40. brian m. carlsonApr 6, 2017
  41. Todd ZullingerApr 6, 2017
  42. Jeff KingApr 6, 2017
  43. Johannes SchindelinApr 7, 2017
  44. Jeff KingApr 10, 2017
  45. Jeff KingApr 6, 2017
  46. Tom G. ChristensenApr 6, 2017
  47. Jeff KingApr 7, 2017
  48. Junio C HamanoApr 14, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.