all: define deprecation policy for old architectures

[rsc]

It would be nice to figure out the general policy for architectures. When do we retire architecture support? What is the cutoff?

In #17082, we announced during the freeze that Go 1.8 will likely be the last to support ARMv5 (GOARM=5), and we heard from a number of commercial users of Go that would like that support to continue.

In #19074, there is a discussion, moved from golang-dev, about retiring POWER5 support in ppc64, to match ppc64le which already requires POWER8. This would affect no known production uses of Go.

It would be nice to have a general policy. Perhaps: as long as we are aware of production use by more than one company we will keep support?

[m3talsmith]

To me it seems that this falls into guaranteed backwards compatibility for major release versions. I have no dog in the fight, as I use none of those architectures, but it is something to consider.

[4ad]

I think we should have some project-level guidelines in place, offering some sort of minimum guarantees to users, but I don't think we should do a project-level decision to remove support just because we don't have to offer support anymore.

So we make a promise to users that we will keep support, and under what conditions (and we might update this promise each release) but we won't necessarily remove support once we don't make that promise anymore.

I think the final decision to remove support from some architecture should be left to the maintainer of that platform. If the maintainer of the platform wants to keep support for old targets, why shouldn't he be allowed to? Target-specific code is well isolated, and doesn't generally impact other architectures, or Go development in general.

In cases where we implement new things, like better shared library support, that are ABI-dependant and require new code to be written to support the old platforms, we will guarantee to do it as long as we made the promise that the target is "supported".

If the target is not "supported" anymore, the maintainer can chose or chose not to implement the new feature. At some point, well past "supported" stage, the maintainer can decide to actually drop support for the target.

Of course, if something exceptional occurs where "unsupported" targets impede the development of Go in general, then a project-level decision should be taken if the maintainer can't keep up with the churn (but this factor is already taken care of the porting policy anyway).

In other words, I want Go to make guarantees to users about what is supported and for how long it will be supported, but I don't want Go to remove support for old targets just because Go doesn't have to support them. Defer that decision to the platform maintainer.

[rsc]

@4ad, the questions I'd like to answer here are:

1. When can we retire support? What are our criteria?
2. What process do we follow to do that, to ensure proper input from and notification to Go users?

This is only about establishing when retiring support is allowed, not when it's required. In the case of #19074, it is precisely the active maintainers who want to retire the support, and we're trying to understand the general conditions under which that's OK.

[rsc]

@m3talsmith, you may believe backwards compatibility mean that, but it doesn't. The doc https://golang.org/doc/go1compat is explicitly about source-level compatibility, meaning the language and libraries. It makes no constraints on the toolchain. Part of the goal of this and the related issues is to understand and agree on exactly what we aim for.

[m3talsmith]

@rsc I do realize the promise is for source level compatibility, and that tools aren't even covered in that promise, but I can't help think of how tightly coupled compiling is to architecture sometimes. It's not a total 1-1 since we often compile for a given architecture from another one, and I think it's not necessarily reasonable to hold to it as a rule, but it is a guideline we could use.

Outside of that, I think @4ad 's idea was a good start with one addendum. If a developer no longer wants to support x architecture, they should at least broadcast their intention to leave, make some effort to gauge the communities continued interest in that architecture, and given a sustained interest, strive to recruit a replacement.

[rsc]

Important considerations:

• Availability of hardware. If the hardware has stopped being made, for example, there's not a clear need to keep it going.
• Actual or expected user base.
• Incurred ongoing costs of keeping old support (builders, compiler code paths, and so on).
• Announcement policy. Like on proposal: all: define deprecation policy for OS versions #19002, announce in the notes for Go 1.N that support will drop in Go 1.(N+1)?

It seems like people agree on the announcement policy. The bigger question is what guidelines there are for when we do or do not drop hardware. 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?

[minux]

@rsc, availability of hardware is really hard to quantify. For example, hardly any vendor still produces Pentium MMX class x86 processors. But our x86 port still targets that. Also keep in mind that vendor stops producing something != something is not used by people.

[rsc]

Accepting proposal for general criteria. Will leave this open until I move this to a wiki page.

[tomihasa]

I have been thinking of using Go in Android apps (Android NDK), how old phones can I support?

[dmitshur]

/cc @cagedmantis @toothrot @andybons FYI.

[rsc]

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