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.

[rsc]

Following my recent comment on #19075, it sounds like we're happy with the "Go 1.N can announce that support for will be dropped in Go 1.(N+1)".

Criteria for the cost-benefit analysis for operating systems parallel the ones for hardware in that issue:

• Availability of and support for the OS. If the OS version is no longer available and/or no longer supported, that reduces the expected benefit.
• Actual or expected user base. If no one is using that version, that reduces the expected benefit.
• Incurred ongoing costs of keeping old support (builders, compiler/runtime/syscall code paths, and so on).

Again it may be that the best we can do ahead of time is list the costs and benefits to consider, but not how they must be weighed.

Is that enough? Other considerations?

[rsc]

Accepted pending wiki page, like #19075.

[binarycrusader]

For what it's worth, I agree with @4ad 's comments on Solaris. Realistically, Go generally only needs to support the latest update release of Solaris (e.g. 11.3).

[stevenh]

With respect to FreeBSD following the official supported versions is an option, which can be seen here:
https://www.freebsd.org/security/security.html#sup

So currently only 10 and 11 are supported, all other version have reached their EOL.

Not sure if that would work for other OS flavours?

[rsc]

Added https://github.com/golang/go/wiki/PortingPolicy#removing-old-operating-system-and-architecture-versions.