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

Proposal to rename Standard 2.1 to 2.2, make 2.1 a Framework compatible subset #1050

Closed
duncand opened this Issue Jan 8, 2019 · 3 comments

Comments

Projects
None yet
2 participants
@duncand
Copy link

duncand commented Jan 8, 2019

I'm looking to provide input on .NET Standard and this appears to be the best place.

See https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/ for reference.

I propose that what is currently planned for .NET Standard 2.1 be pushed back to .NET Standard 2.2, and that .NET Standard 2.1 instead just have the subset of those changes that are implementable on .NET Framework.

While going forward, .NET Standard after 2.0 is mainly adding new features that are not practical to implement in .NET Framework, some of the proposals for 2.1 contained bringing out some things that already existed but missed the 2.0 window.

If we do what I propose, then we have a last chance to increase the API surface that can run everywhere, before it is permanently shut out due to releasing a .NET Standard version that Framework can't run, given that each increasing Standard version is a superset of what came before.

@duncand

This comment has been minimized.

Copy link

duncand commented Jan 8, 2019

Alternately, and perhaps better, I propose renaming the current Standard 2.1 to Standard 3.0.

This is because in a sense dropping Framework support is a breaking change, and it leaves all 2.x open to just include .NET Standard versions that explicitly are compatible with Framework.

@terrajobst

This comment has been minimized.

Copy link
Member

terrajobst commented Jan 11, 2019

We've discussed this but the amount of APIs that would be in the .NET Framework 4.8 compatible subset of .NET Standard 2.1 isn't big enough to justify the complexity of having to ship two different .NET Standard versions.

@terrajobst terrajobst closed this Jan 11, 2019

@duncand

This comment has been minimized.

Copy link

duncand commented Jan 11, 2019

Thank you for your response. It is understandable that there isn't enough new Framework-implemented API surface to make it worth having another compatible release. I do however still suggest that renumbering 2.1 to 3.0 for the sole reason that it is not Framework compatible would be a good idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment