all: announce end of support for old macOS releases

bradfitz commented 6 years ago

Note, Aug 2022: See https://github.com/golang/go/issues/23011#issuecomment-738395341 for the macOS deprecation schedule.

Apple continues to put out new macOS releases. We can't run builders for all of them forever.

I propose we announce in the Go 1.10 release notes that Go 1.10 will be the last release to officially support macOS 10.8 (Mountain Lion).

macOS 10.8 was last updated Oct 3, 2013, over 4 years ago.

(macOS 10.9 was last updated Mar 21, 2016, 19 months ago, which is somewhat more recent)

Apple doesn't publish official End-of-Life dates for macOS versions, but I read that their security policy is that they issue security updates for the past 3 releases.

Given that they're on 10.13 now, that means 10.13, 10.12, and 10.11 are supported by them.

Our policy of additionally supporting 10.10 and 10.9 in Go 1.11 would be even more.

/cc @rsc @ianlancetaylor

rsc commented 6 years ago

I just came here to suggest the same thing. SGTM.

gopherbot commented 6 years ago

Change https://golang.org/cl/82275 mentions this issue: doc/go1.10: preannounce removal of OS X 10.8 support in Go 1.11

rsc commented 6 years ago

Looks like we could plausibly drop support in Go 1.11 for both Mountain Lion (as previously agreed) and also Mavericks. By the time Go 1.11 comes out in August 2018, Mavericks will have gone two years since its last security update.

version	released	updated	security update
OS X 10.8 Mountain Lion	Jul 2012	Oct 2013 (10.8.5)	Aug 2015 (2015-006)
OS X 10.9 Mavericks	Oct 2013	Sep 2014 (10.9.5)	Jul 2016 (2016-004)
OS X 10.10 Yosemite	Oct 2014	Aug 2015 (10.10.5)	Jul 2017 (2017-003)
OS X 10.11 El Capitan	Sep 2015	Jul 2016 (10.11.6)	Dec 2017 (2017-005)
macOS 10.12 Sierra	Sep 2016	Jul 2017 (10.12.6)	Dec 2017 (2017-002)
macOS 10.13 High Sierra	Sep 2017	Dec 2017 (10.13.2)	—

gopherbot commented 6 years ago

Change https://golang.org/cl/83795 mentions this issue: doc/go1.10: preannounce deprecation of OS X 10.9 Mavericks

rsc commented 6 years ago

Filed #23122 for the actual removal work (whatever that is). Looks like we'll be caught up once Go 1.11 is out and then once caught up we should probably plan to deprecate one Mac OS version each year, alternating between preannounce and remove.

Go 1.12 preannounces dropping Yosemite Go 1.13 drops Yosemite Go 1.14 preannounces dropping El Capitan Go 1.15 drops El Capitan Go 1.16 preannounces dropping Sierra etc.

rsc commented 6 years ago

Let's make this issue the open-forever tracking bug for this sequence. Moving to Go 1.11; once Go 1.12 milestone is created, can move to Go 1.12.

rasky commented 6 years ago

One bit of information ignored by the above table is which Mac hardware is dropped by each OS versions. Some macOS versions are "tocks" that drop hardware support, others are "ticks" that don't drop hardware support. I think this should be analyzed when taking decisions.

Also this page reports the usage share between different macOS versions: http://gs.statcounter.com/macos-version-market-share/desktop/worldwide

Mavericks is about 5% of all Macs, while Mountain Lion is non existing.

rsc commented 6 years ago

The statcounter.com page makes no sense to me. I don't believe their numbers at all.

gopherbot commented 5 years ago

Change https://golang.org/cl/151360 mentions this issue: doc: preannounce dropping macOS 10.10 support

gopherbot commented 5 years ago

Change https://golang.org/cl/151361 mentions this issue: doc: fix formatting for Darwin entry

robaho commented 5 years ago

@rsc what is wrong with the statcounter? you just read it down in a line - they all seem to add to 100% (or close enough to it - there are probably lots of versions in use that they drop due to very low usage, and combined maybe less than 5% ?).

robaho commented 5 years ago

Also, is there some reason the OSX support is being terminated so early compared to other platforms? Windows server 2008 is being supported for Go 1.11 but the latest OS X version is 2013?

bradfitz commented 5 years ago

Size of test matrix, frequency of OS releases, upgrade rates.

robaho commented 5 years ago

Understood, but as a developer of OS X software I’m surprised at the number of generations actually in use. Plus, I would think the apis in use by Go runtime are fairly static and unlikely to change. It would be a shame that recent builds just stopped working because of a minor runtime change that used a new feature when an older one would suffice. I can definitely see “only verified on xxx” with an eye towards not intentionally breaking things...

randall77 commented 5 years ago

I can definitely see “only verified on xxx” with an eye towards not intentionally breaking things...

I don't think anyone is planning on intentionally breaking anything. This is more of a "only verified on" situation.

With the upcoming 1.12 we've moved from using raw system calls to libSystem system calls on Darwin. That should hopefully lessen the chance of needing Darwin-version-specific code in the distribution. That in turn might help avoid unintentional breakages.

robaho commented 5 years ago

Intentionally was the wrong word, should of been knowingly. That is good news on the Darwin impl front.

bradfitz commented 5 years ago

Well, we have intentionally broken things for unsupported versions in the past if it means we can simplify code. And in several cases, simplifying code was part of the motivation of removing support for an old OS version.

robaho commented 5 years ago

I understand. Seems to me though the bar should be pretty high for a tool that is used to build other tools, as the destination platform may not be fully represented (embedded systems, etc. that don't show up on penetration lists) - but just MO as always.

gopherbot commented 5 years ago

Change https://golang.org/cl/174521 mentions this issue: doc/go1.13: start doc, note macOS, FreeBSD deprecations

andybons commented 5 years ago

From discussions with Chrome team, we have no plans to deprecate macOS 10.11 for Go 1.14. So nothing to announce for 1.13. Kicking the can down the road.

probonopd commented 5 years ago

Please never drop any Mac OS X, OS X, and macOS releases. Ever. One of Go's main advantages is that it builds static binaries, and hence binaries don't rely on the libraries that come with the OS. By mandating that the resulting binaries need to run on all Mac OS X, OS X, and macOS releases, Go would have a huge advantage over other languages.

Binaries that can run on, say, Mac OS X 10.4 can still run on whatever ever-changing macOS is out there today, right? (Apart from 386 vs. x86_64). Apple users are sick and tired of the constant urge to update not only the software, but also the machines.

Point in case: 2007-ish Macs that would otherwise be perfectly capable machines (e.g., when using Linux) do not even get the latest macOS anymore. This is not only expensive, but also planned obsolescence which is evil to the environment.

probonopd commented 5 years ago

Looks like we could plausibly drop support in Go 1.11 for both Mountain Lion (as previously agreed) and also Mavericks.

Why? To force users on the latest macOS releases, and hence force them to throw away perfectly good machines and buy new hardware?

Apple continues to put out new macOS releases. We can't run builders for all of them forever.

Why not just build on the oldest one, the binaries should also run on newer systems.

bradfitz commented 5 years ago

@probonopd, sorry, that's not happening.

There's a maintenance cost for each operating system we support, especially for older ones, holding us back, making us keep workarounds alive, forcing us to keep multiple codepaths for old APIs (when new ones aren't available) vs newer APIs (when the older ones have been removed later), etc.

probonopd commented 5 years ago

Why not build only for the old Mac OS X versions? Binaries built on older Mac OS X shall run on newer macOS versions, too (unless Apple broke them).

Never use new APIs when old ones are there. Because not everyone has the new ones, but everyone has the old ones. This is how "backward compatibility" works. My 2 cents.

randall77 commented 5 years ago

Binaries built on older Mac OS X shall run on newer macOS versions, too (unless Apple broke them).

Apple is actively trying to break them. They are intentionally forcing people off of old APIs. In most cases the binaries will still work, but they won't be signable/notarizeable/whatever they call it.

So we have to move to newer APIs so that people can notarize their binaries. So that means we can't support older OS versions that don't have the new APIs. Unless we keep multiple implementations and have a build-time switch. Or we give up on Go binaries being notarized. None of these are great options, but we have to pick one.

probonopd commented 5 years ago

Notarized. This is exactly the kind of stuff why I am trying to stay away from the recent macOS releases and am still on 10.9. From release to release, macOS seems to become more cumbersome. Personally, I could live very well without app store and notarization, but I guess it may be important for some users. Oh well.

robaho commented 5 years ago

I think with current and future security threats, notarized is a must have feature - maybe a very small percentage of very tech savvy users could get by without it.

On Nov 1, 2019, at 11:05 PM, probonopd notifications@github.com wrote:

Notarized. This is exactly the kind of stuff why I am trying to stay away from the recent macOS releases and am still on 10.9. From release to release, macOS seems to become more cumbersome. Personally, I could live very well without app store and notarization, but I guess it may be important for some users. Oh well.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

robaho commented 5 years ago

I was only offering it up as evidence that supporting later releases is a wise move.

On Nov 2, 2019, at 9:32 AM, Brad Fitzpatrick notifications@github.com wrote:

Please find another forum to discuss everybody's operating system preferences and skill levels.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.