Decide on version number for .NET Standard vNext

[terrajobst]

From the planning doc:

• Version number. In contrast to .NET Standard 2.0, which was a massive update in terms of APIs and the .NET Framework compatibility mode, this update seems relatively incremental. Also, the payload is comparable to .NET Core 2.1, hence .NET Standard 2.1 seems to make the most sense.
  • .NET Core and .NET Standard aren't the same thing. People will expect that the next version is 3.0 as that's what we called .NET Core. However, the API set is closer to 2.1 and argubly makes more sense within the context of the standard.

[jcapellman]

I think keeping it in line at 2.1 with .net core 2.1 will cut down on the confusion.

[clairernovotny]

What would the plan be for one based on .NET Core 3.0, .NET Standard 3.0? It is likely a reasonable assumption that UWP, Mono (and thus Xamarin) will add types from .NET Core 3, thus needing a revision.

[benaadams]

Depends timeframes for std and .NET Core 3.0 apis and if they would be a vNext+ standard or included in vNext standard.

e.g.

1. Skip 2.1, include minimal? set of Core 3.0 (most is NuGets?) release std around .NET Core 3.0
2. Do std 2.1 for now; and additional std 3.0 for .NET Core 3.0 timeframe

Might as well match .NET Core version numbers while the serendipity exisits

[terrajobst]

What would the plan be for one based on .NET Core 3.0, .NET Standard 3.0?

We decided to version the upcoming release of .NET Core as 3.0 because it adds a major set of APIs and scenarios, namely desktop development on Windows with WPF and WinForms, neither of which are applicable to .NET Standard. I expect some APIs from that time frame to be sensible for .NET Standard (e.g. any of the recent pull requests that will go in for .NET Core 3.0) but that will likely be a small-ish set so that the standard would rev from 2.1 to, say, 2.2.

In general, we should stop treating .NET Core and .NET Standard as somehow being related. The fact that most of the API candidates are originating from .NET Core is irrelevant. In principle they could come from any of the following .NET implementations and none of their version numbers are aligned with .NET Standard either. Said differently, .NET Core isn't special in any way. It's just yet another implementation of the .NET Standard.

[CShepartd]

.NET Core and .NET Standard should be separated at versioning the same as should be separated"platform specific" API from .Net Standard (only multi platform API should be supported)

[thomasclaudiushuber]

In general, we should stop treating .NET Core and .NET Standard as somehow being related

I think if you bring out .NET Standard 2.1, many developers will make a relation to .NET Core 2.1.

Did you ever think about ditching this whole major/minor versioning for .NET Standard and use an API level like Android does? If we would have started with that, the next version would be .NET Standard 9. Such a rolling version number makes it clear that there's no relation to any .NET platform.

.NET Standard (old Versioning)	.NET Standard (new versioning)
1.0	1
1.1	2
1.2	3
1.3	4
1.4	5
1.5	6
1.6	7
2.0	8
vNext	9

Today such a change might be confusing, as the new .NET Standard 7 (which is the old 1.6) would be smaller than the old 2.0.

To avoid this, we could start with rolling numbers with vNext, which means vNext is .NET Standard 3:

.NET Standard (old versioning)	.NET Standard (new versioning)
1.0	1.0
1.1	1.1
1.2	1.2
1.3	1.3
1.4	1.4
1.5	1,5
1.6	1.6
2.0	2.0
vNext	3.0, or better just 3
vNextNext	4
vNextNextNext	5

Is it really important to see that there's a huge difference between 1.6 and 2.0? At least not for me. It's more important to know which .NET Standard version can be used on which .NET platforms.
If the API surface of a new .NET Standard version is much bigger than the API surface of the previous .NET Standard version doesn't matter, as long as I can use my library on the required .NET platforms. That's the reason why I don't think it's important to express the size of the changes in a .NET Standard version with its version number.

Beside this fact, I think a rolling API level/.NET Standard version number would also make life much easier for you. You can focus on the APIs, and it's clear, bringing in new APIs means just version++.

Here for reference the API levels used by Android:
https://docs.microsoft.com/en-us/xamarin/android/app-fundamentals/android-api-levels?tabs=vswin

[thomasclaudiushuber]

I just read this here after my post above: https://github.com/terrajobst/standard/blob/511b206541d16f0c24c2ba746cb3abde311b1b98/docs/planning/netstandard-vnext/README.md#open-issues

There you already write

Or we could go with levels (10-16, 20, etc.)

Yes, I think levels are the way to go. What I don't like are the gaps in the levels.

[clairernovotny]

Agree levels make a lot of sense as there's already established precedent for it with Android and it helps differentiate the standard from .NET Core. With the version numbers being so close today, I think it's inevitable people will tie them together.

[CShepartd]

I think if you bring out .NET Standard 2.1, many developers will make a relation to .NET Core 2.1.

Lowering the level to the lowest intelectual power isn't good idea. We need to clearly see the future and have hope to ppl will know difference between .Net Standard and implementations like .Net Core/Framework/Other by writing good docs

[thomasclaudiushuber]

@onovotny Exactly, close version numbers will be tied together.

What would be if talk in the future about ".NET Standard levels" or ".NET Standard API levels" instead of ".NET Standard versions" and if we would apply the levels starting with 1?

Let's go with this table:

.NET Standard version	.NET Standard level
1.0	1
1.1	2
1.2	3
1.3	4
1.4	5
1.5	6
1.6	7
2.0	8
vNext	9

Wouldn't it be possible to use a TFM like this:

  <PropertyGroup>
    <TargetFramework>netstandardlevel3</TargetFramework>
  </PropertyGroup>

and the above code would be equivalent with this:

  <PropertyGroup>
    <TargetFramework>netstandard1.2</TargetFramework>
  </PropertyGroup>

And maybe if you're using the old TFMs, the compiler could give a warning that you should use the TFM netstandardlevel3 instead of netstandard1.2.

When you create a new .NET Standard library in Visual Studio, it would create this when the vNext .NET Standard is out:

  <PropertyGroup>
    <TargetFramework>netstandardlevel9</TargetFramework>
  </PropertyGroup>

[CShepartd]

some ppl dont understand difference between .Net Standard 2.0 and .Net Core 2.0
great idea! make one new thing: .Net Standard Level

I hope you are joking @thomasclaudiushuber with your posts

[thomasclaudiushuber]

I guess you know that your comic has nothing to do with this versioning issue. Today we have 8 .NET Standard versions, and with vNext we will have 9.

The topic of this issue is not like in your comic if there is going to be another version, because there will definitely be another version of .NET Standard. This issue is about what to call that next version, which is .NET Standard number 9. At least this is how I understood the title of this issue:

Decide on version number for .NET Standard vNext

But what should .NET Standard number 9 be: version 2.1, 3.0 or should the .NET team switch to levels?
And especially Why?

I brought in my thoughts. If you have arguments against levels or other arguments for new versions, bring them up here.

Just telling me or others things like

Some ppl dont understand difference between .Net Standard 2.0 and .Net Core 2.0

or

I hope you are joking

doesn't help anyone here. Tell the world why you think my idea is not good and bring up something that makes more sense from your point of view. This is how we can move forward and have a good discussion here.

Thanks,
Thomas

[clairernovotny]

@thomasclaudiushuber I don't think we need to introduce a new concept or TFM. We can't use existing numbers because they'd conflict and I don't see a huge amount of value in renumbering old versions (whose usage is in decline).

I'd probably jump directly to netstandard3 instead of 2.1 and then nothing breaks (or needs to change on the nuget side either).

[thomasclaudiushuber]

@onovotny Yep, true, good arguments to keep the old stuff just as is.

Jumping directly to netstandard3 sounds good to me. And from there on the version number could be incremented by 1 with every new .NET Standard version. Then we would have something like a level from there on.

The question is then if it is just .NET Standard 3 or .NET Standard 3.0. I would go for just 3 to make it clear that from here on a rolling number is used. A future like this looks good to me: