On Fri, Dec 02 2022, Victoria Dye wrote: > Ævar Arnfjörð Bjarmason wrote: >> >> On Fri, Dec 02 2022, Jeff Hostetler wrote: >> >>> On 12/2/22 1:02 PM, Ævar Arnfjörð Bjarmason wrote: >>> So, based on the ages of those two Apple releases, I'd like to think >>> that we're fine just switching over and not having to ifdef-up the >>> config.mak.uname. (If it were a more recent change in the OS, then >>> yeah the answer would be different.) >>> >>> Thoughts ??? >> >> That seems reasonable to me, but it came out in 2001, and we'd be moving >> the dependency to a 2007 version. >> >> Is that OK? No idea, I don't know how old of an OSX version people >> reasonably run & want to compile Git on. > > I appreciate the diligence, but I don't think continuing this discussion > will be productive use anyone's time. It's quite useful in general to know the lower boundaries of what versions of OS's are supported at all. For example, we support non-GNU iconv implementations that have some weird edge cases. As the config.mak.uname shows OLD_ICONV is required for OSX 10.4 or later. If we know we'd like to draw a hard line at OSX 10.5 we can scratch it off the list of platforms we care about. Anyway, that larger topic aside. All I'm suggesting here is that the proposed patch seems to at least soft-deprecate versions of OSX we supported before. Maybe that's fine, but the commit message didn't get across whether that was considered, part of the plan etc. > Apple doesn't seem to provide official end-of-life dates for their OS > versions, but we can extrapolate from the list of obsolete hardware [1] that > it likely doesn't support OS versions older than 2014; that's corroborated > by their official set of release notes going only as far back as 10.14, > released in 2018). In other words, I think it's safe to say that a version > supplanted in 2009 is old enough to not warrant Git support. I wish :) It may happen to be true for OSX, and I suspect that OS has a relatively aggressive timeline as OS's go, as opposed to AIX or something, which people tend to run long past EOL. But our support for OS versions has neither historically or currently mirrored EOL dates. A lot of those are *very* aggressive, e.g. FreeBSD's releases go EOL around a year or so after release, and we certainly support building on way older FreeBSD than that: https://www.freebsd.org/security/unsupported/ For some other in-tree software we're >10 yrs past EOL: https://lore.kernel.org/git/221124.865yf4plw1.gmgdl@xxxxxxxxxxxxxxxxxxx/ In general I think OS EOL's are most useful as an indicator of what versions of that OS you'd want to run in some Internet-connected high-vulnerability scenario. But git gets ported and backported to a long tail of systems way beyond that. Eventually we do need to let got, but we've generally drawn the line at some fuzzy notion of when users don't care anymore, along with whether it's worth the effort to find out.
