proposal: all: define deprecation policy for OS versions

[mikioh]

As of 31 December 2016, 9-STABLE branch was discontinued; https://www.freebsd.org/security/security.html and Go 1.8 supports 8-STABLE through 9-STABLE; https://github.com/golang/go/wiki/FreeBSD. I think there's no reason to support releases that never come even with security fixes. Considering the transition period, I propose to drop the support for FreeBSD 9 or below at the next release of Go 1.9.

Thoughts?

[bradfitz]

SGTM to this non-FreeBSD user at least. I seem to recall hearing that FreeBSD users update pretty regularly. Is that true?

@minux, @mdempsky, @adg?

[adg]

We've dropped support for older OSes in the past because of the maintenance burden. Is it difficult to keep supporting the older versions? Or is it just that you would prefer to clean things up? I'm running FreeBSD 10, FWIW.

[minux]

Production FreeBSD systems are indeed upgraded regularly. But Go is a programming language, not a regular application. It's conceivable that people might want to run Go on older, EOL'ed systems. I agree with @adg. If it's not too much burden to support EOL'ed systems. we probably should keep the support a little longer. As a data point, gcc obsoleted the support for Solaris 9 in GCC 4.9 (April 2014), and removed its support in GCC 5.0 (April 2015) when the extended vendor support for Solaris 9 ended in 2014. https://gcc.gnu.org/ml/gcc-patches/2013-05/msg00728.html I think we could match the gcc plan by dropping support for FreeBSD 8 (EOL August 1, 2015) in Go 1.9, and drop support for FreeBSD 9 (EOL Dec 31, 2016) in Go 1.10. That is, we remove support for a version at least one year after its official EOL date. In fact, for OS X, we support 10.6 until Go 1.5 (Aug 2015), four years after the last 10.6 release (10.6.8 June 23, 2011). I know OS X 10.6 is a little different, because it's the last release to support 32-bit hardware, but my point is that we shouldn't aggressively deprecate old systems like a regular application software (e.g. Chrome).

[reezer]

Something that might be worth mentioning is that the ports collection (so the "official" packages) rather quickly had various commits to remove compatibility code for FreeBSD 9. So third party software might break on a larger scale.

On the comment of quick updates I also want to mention that the first release of the FreeBSD 10 branch was in January 2014, which means that there have been three years of time to do a major upgrade.

Also currently FreeBSD 10 and FreeBSD 11 are supported and FreeBSD 12 is the development branch.

That is not meant to be an argument for or against this proposal, but just meant to give some context to non-FreeBSD users.

[rsc]

We don't have a clear policy about when to drop support for specific systems. It would be nice if we could establish a general rule.

Maybe the policy should be: after an operating system version is no longer supported by the vendor, Go may drop support after the next two releases, and the release notes for the final release with support must mention that support is going away in the next release.

For example, FreeBSD 9 was dropped on Dec 31 2016; the next two Go releases after that are Go 1.8 and Go 1.9, and we'll likely drop in Go 1.10, but if so we must announce that in Go 1.9's release notes.

-rsc for @golang/proposal-review

[mikioh]

Looks like this issue is hijacked. I'll open another issue for code cleanup.

[4ad]

As a data point, gcc obsoleted the support for Solaris 9 in GCC 4.9 (April
2014), and removed its support in GCC 5.0 (April 2015) when the extended
vendor support for Solaris 9 ended in 2014.
https://gcc.gnu.org/ml/gcc-patches/2013-05/msg00728.html

Minor nitpick, Solaris 8 and Solaris 9 are still supported, they
are in what Oracle calls "Sustaining Support phase" for an indefinite
period.

However, we never supported Solaris 8, 9, or 10, so we don't have
to worry about any of that.

However, IIRC correctly Windows XP is still supported in the embedded
SKU, or if you have a special service contract. I think from the
perspective of the Go project, we should continue to treat Windows
XP as a supported system.