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

Make EventLoopFuture.hopTo(eventLoop:) public again. #963

Merged
merged 1 commit into from
Apr 11, 2019

Conversation

MrMage
Copy link
Contributor

@MrMage MrMage commented Apr 11, 2019

This was accidentally made internal with #947.

Maybe there should be a separate test case file (with a non-@testable import) that verifies that all public interfaces are still present?

@MrMage
Copy link
Contributor Author

MrMage commented Apr 11, 2019

@swift-nio-bot test this please

Copy link
Member

@normanmaurer normanmaurer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ouch... LGTM. Thanks!

@normanmaurer
Copy link
Member

Verify API / ABI breakage would be good for sure... I wonder if there is anything similar to what we have in java to verify this sort of stuff in netty:

https://siom79.github.io/japicmp/MavenPlugin.html

Basically it always confirms the current "branch" to the last stable release and fails the build if there is an API / ABI issue.

@ffried ffried mentioned this pull request Apr 11, 2019
@Lukasa
Copy link
Contributor

Lukasa commented Apr 11, 2019

Verifying ABI breakage is not relevant due to the lack of stable ABI on Linux, so we don't need to worry about that.

Verifying API breakage in Swift is an unsolved problem. We'd have to invest time in writing tooling that presumably uses SwiftSyntax or something similar to generate an idea of what the public interface to SwiftNIO even is, and then to write diffing tools that understand the semantic nature of the changes. This is a hard problem.

Writing tests that don't use @testable imports is always better: we should consider whether we can split these future tests up to avoid doing so.

@Lukasa Lukasa added the semver/patch No public API change. label Apr 11, 2019
@Lukasa Lukasa added this to the 1.14.1 milestone Apr 11, 2019
@Lukasa Lukasa merged commit ba7970f into apple:nio-1.14 Apr 11, 2019
@MrMage
Copy link
Contributor Author

MrMage commented Apr 11, 2019

Verifying API breakage in Swift is an unsolved problem. We'd have to invest time in writing tooling that presumably uses SwiftSyntax or something similar to generate an idea of what the public interface to SwiftNIO even is, and then to write diffing tools that understand the semantic nature of the changes. This is a hard problem.

I think Xcode sometimes gets confused when Cmd-clicking a library symbol and only shows that library's exports, rather than the implementation source file. Maybe that could be a place to start. I could imagine that it would be easier to simply wait until that tooling has improved though, rather than invest unreasonable amounts of time now.

@weissi
Copy link
Member

weissi commented Apr 11, 2019

Ouch! I think the Swift team somewhere have a public API diffing tool. We need that kind of thing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
semver/patch No public API change.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants