Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

all: define deprecation policy for old architectures #19075

Open
rsc opened this issue Feb 14, 2017 · 9 comments

Comments

@rsc
Copy link
Contributor

commented Feb 14, 2017

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?

@rsc rsc changed the title proposal: all: define support criteria for old architectures proposal: all: define deprecation policy for old architectures Feb 14, 2017

@m3talsmith

This comment has been minimized.

Copy link

commented Feb 14, 2017

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

This comment has been minimized.

Copy link
Member

commented Feb 14, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Feb 15, 2017

@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

This comment has been minimized.

Copy link
Contributor Author

commented Feb 15, 2017

@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

This comment has been minimized.

Copy link

commented Feb 16, 2017

@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

This comment has been minimized.

Copy link
Contributor Author

commented Feb 27, 2017

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 #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

This comment has been minimized.

Copy link
Member

commented Mar 15, 2017

@gopherbot gopherbot added this to the Proposal milestone Mar 20, 2017

@gopherbot gopherbot added the Proposal label Mar 20, 2017

@rsc

This comment has been minimized.

Copy link
Contributor Author

commented Mar 27, 2017

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

@rsc rsc self-assigned this Mar 27, 2017

@rsc rsc added Proposal-Accepted and removed Proposal labels Mar 27, 2017

@rsc rsc changed the title proposal: all: define deprecation policy for old architectures all: define deprecation policy for old architectures Mar 27, 2017

@tomihasa

This comment has been minimized.

Copy link

commented Mar 29, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.