.NET Standard vNext Review Process

[terrajobst]

In order to review .NET Standard vNext, I propose the following review process:

1. Review & approve the planning document. It covers the high-level goals of the release. I don't expect much push back there, but I'd be interested if folks have any questions or would like to add specific goals.

2. Review & approve individual API changes with runtime-impact. Those are likely the hardest ones to support, so I'd like to front load concerns in this space.

3. Review & approve remaining API changes. These should be easy now 😄

4. Decide on version number. This shouldn't necessarily the last thing, but I think the version number depends on the scope. So we shouldn't necessarily decided too early either.

@dotnet/nsboard, any concerns or questions about this process?

[joshpeterson]

Will we add additional APIs to a given version over time, or will we move through the process steps 1 - 4, then ship the version decided in step 4, then start again?

[terrajobst]

Great question. In order to reduce complexity I'd prefer to focus on a single release and only split the API surface into multiple versions if enough platform implementers say that they cannot implement all of it at once.

[joshpeterson]

I like that approach. So once we reach step 4 in this process, then can we "ship" .NET Standard vNext?

[terrajobst]

Well, once we reach step 4 the standard is approved/ratified. In order to ship other work items need to happen (such as packaging and building the reference assemblies, updating VS and .NET SDK to include them etc). But those work items don't require work or sign-off by the .NET Standard board. We'll likely track many of these work items here, but some probably go to other repos (like dotnet/sdk or dotnet/core-setup).

[terrajobst]

Looks like we're in agreement then!