Split package for CgRPC and NIO variants

[glbrntt]

The CgRPC and NIO variants are disjoint (well, almost: StatusCode.swift and echo.proto are shared) but live in the same Swift package and repository.

This has a couple of drawbacks:

• Both are tied to the same Swift version.
• They share a build system and CI.

In the NIO implementation we would like to use a newer version of swift-nio-http2 to drop the nghttp2 dependency. Doing this requires using NIO 2.0 which is Swift 5 only.

Two obvious approaches are:

1. separate repositories (i.e. "grpc-swift" and "grpc-swift-nio"), and
2. separate branches (with different major versions).

Part of this rests on how long the CgRPC implementation will be around. If support is dropped in favour of the NIO implementation then separate branches with different major release versions should be fine. If both are supported long term then separate repositories would probably make more sense since they are separate projects.

[MrMage]

I agree that this is probably going to become necessary, and having separate repositories would probably make it easier to use both libraries at the same time for a transition period. My only concern about opening a separate repository would be possible "bureaucratic overhead" and a loss of mind share, because it would get harder for people to discover the NIO variant of the client.

On the other hand, I do hope that we'll be able to at least deprecate the non-NIO variant this year, at which point the NIO variant would become the "recommended" variant.

[glbrntt]

On the other hand, I do hope that we'll be able to at least deprecate the non-NIO variant this year, at which point the NIO variant would become the "recommended" variant.

If that's the case then separate branches should work well. We could always move the CgRPC variant out of master to increase discoverability for the NIO variant ;)

[glbrntt]

What are your thoughts on this @timburks @rebello95?

[MrMage]

@glbrntt to unblock you, I could create a nio branch that we merge all upcoming work on SwiftGRPCNIO into. It's unlikely that we'll need to cut a release based on NIO changes anytime soon, so this would let us continue working on the NIO variant while leaving us the option to converge both branches again in the future (if possible) — even if you need to make a few small changes to disable the gRPC-Core version on the nio branch for the time being. (That could be done by simply removing the corresponding target from Package.swift.) Alternatively, we could still split out the NIO work into a separate repository later on.

I think this would be an unbureaucratic way forward which still leaves all options open for the future. WDYT?

[glbrntt]

Ah, that's a very sensible idea @MrMage, that would be great.

[MrMage]

Great! I'll open a nio branch once #395, if nobody objects. This should be low-impact, so we can still change course later on.

[rebello95]

Creating a NIO-specific branch for now seems reasonable to me 👍

[glbrntt]

@MrMage can you create that branch since #395 is merged?

[MrMage]

Yes, sorry! Done.

[glbrntt]

Thanks!