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

Notice: Upcoming Experimental Balancer/Resolver API Changes #3180

Closed
11 tasks done
dfawley opened this issue Nov 14, 2019 · 3 comments · Fixed by #3742
Closed
11 tasks done

Notice: Upcoming Experimental Balancer/Resolver API Changes #3180

dfawley opened this issue Nov 14, 2019 · 3 comments · Fixed by #3742
Labels
P2 Type: API Change Breaking API changes (experimental APIs only!)

Comments

@dfawley
Copy link
Member

dfawley commented Nov 14, 2019

As we work toward stabilization of the experimental resolver/balancer plugin APIs, the gRPC team will be making several non-backward compatible changes to enable new functionality and better extensibility for the future. These changes are not strictly following semantic versioning or the Go compatibility promise, but they are in accordance with our versioning policy as the changes are limited to experimental APIs.

Items will be checked off of the following list as they are completed.

Cleanups

For the short-term, to allow an easier migration, type aliases will be put in place for the old symbols.

balancer Package

Changes planned for the 1.27 release (December 17 - January 28)

Changes planned for the 1.30 release (March 21 - June 2)

Changes planned for the 1.31 release (June 2 - July 14)

The resolver and balancer APIs will be kept in the experimental state after these changes, as there may be more breaking changes needed in the near future.

@samsalisbury
Copy link

samsalisbury commented Apr 6, 2020

Hi @dfawley, even though these changes were to "experimental" APIs, multiple external projects do depend on them, at different versions of this library. This is a significant problem for the Go ecosystem because any project trying to import recent versions of (for example) both cloud.google.com/go and go.etcd.io/etcd are unable to build, since they both depend different versions within major version 1 of this module, one before and one after these breaking changes. This means downstream projects are stuck on much older versions of those libraries as well as grpc-go itself. Would you consider changing the versioning policy to observe the Go compatibility promise?

In the meantime, would you consider adding type aliases so that code which relies on both the old and new names of these types can still compile?

@dfawley
Copy link
Member Author

dfawley commented Apr 6, 2020

@samsalisbury ,

Would you consider changing the versioning policy to observe the Go compatibility promise?

It was a mistake for any other projects to use these packages without transitively marking themselves as experimental. Unfortunately the Go compatibility promise doesn't have any convention that allows us to experiment with APIs to see what will work well for our users or to release functionality before it's fully supported for advanced users that can tolerate instability. We've discussed using separate modules (at v0) for this purpose, but it oftentimes isn't technically possible to achieve the separation needed for this.

In the meantime, would you consider adding type aliases so that code which relies on both the old and new names of these types can still compile?

We had type aliases in place for the 1.26 release, and marked them as deprecated, in order to allow projects a chance to do a smooth migration. Unfortunately, we cannot leave type aliases in place forever; projects will need to upgrade.

Sorry for any disturbances this has caused.

@samsalisbury
Copy link

Hi, thanks for the response @dfawley, most conversation happening in #3500 now I think. I think it seems like a reasonable desire (to want to add things that should not be depended on yet) but unfortunately I don't think relying on the eternal vigilance of multiple parties to always respect this rule is likely to work in the long term, especially as it is special to this repository or organisation. The good thing about go's compatibility rules are that they are at least a single standard that everyone could probably bend to if they wanted, for the sake of the ecosystem. Rather than relying on eternal vigilance, they have built tools that break builds when these rules are not followed, which at least is some kind of feedback projects will hit eventually.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
P2 Type: API Change Breaking API changes (experimental APIs only!)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants