Create platform-support.md

[CharliePoole]

Fixes #1414

Note that I cancelled the builds, which make no sense in this case. Just using the PR as a way to review the document.

[manfred-brands]

Looks good

[CharliePoole]

Leaving this till the weekend in case there are is any discussion.

[mikkelbu]

Looks good. I've just a couple of comments

[mikkelbu]

What is the reason for removing the comments in the final version? I know that having this information in the document will require us to update it now and then, but my personal feeling is that the more explicit we can be the better

[stevenaw]

Changes look good, great to see you again @CharliePoole

As a question for future changes. Do we see us eventually listing an explicit "support" matrix with "EOL" dates of specific runtimes, or is this intended to be more general to describe our high-level approach?

[CharliePoole]

@stevenaw A matrix is a good idea. I'll have to think about how to express firm vs soft dates if we want to retain some flexibility. This may also relate to whether we have pluggable agents in v4.

[CharliePoole]

Updated based on your comments and ready for final review.

[manfred-brands]

One small typo

[CharliePoole]

@OsirisTerje Comments? (Particularly with regard to removing agents)

[OsirisTerje]

Looking at download numbers for NUnit 4, which dropped some older platform version, but also had some other breaking changes that may have affected the numbers,:

The last 6 weeks numbers are

Version	Downloads	Breaking changes
3.11.0	0.3 mill
3.12.0	1.2 mill.	Drop framework 2.0
3.13.2	1.1 mill.	None
3.13.3	3.8 mill.	Dropped .net core 2.1
3.14.0	1.3 mill.	None
4.0.1	0.7 mill.	Platforms >= 4.6.2 and .net 6 , moved classic asserts to new namespace
4.1.0	2.1 mill	None

So dropping framework 2.0 seems to be a no-brainer. Dropping net core 2.1 also doesnt seem to be any issue, only 2.6 mill downloads on earlier version.

Why the 3.13.3 didn't upgrade to 3.14.0 - don't understand, but can be they don't upgrade once included. If people using the 3.X are those people who don't upgrade (except the 1.3 mill out of 7.5 mill or so), then there is little point backporting stuff to new version in the 3.X series.

The 4.0.1 version was obviously an issue for people.
But it picked up with 4.1, but there are still many more people using earlier versions and not upgrading.

So, based on this, I do believe people react to not supporting older versions of the dotnet platform. On the other side, it also looks like many people simply don't upgrade their packages.

So if we want to get people to use the NUnit tools, then I am starting to believe we need to cater for those lagging behind wrt to what framework they're running on. Just moving up may not be for everyone.

I don't think NUnit has enough leverage to make people upgrade their frameworks, they would then much more just not upgrade. So perhaps we should be more careful, and keeping version for longer, even if the package gets bigger ?
Afaik no one has complained about the package size yet.

So setting fixed dates for when we retire them may be too much trying to predict the future.

We do lack metrics however, and I am not at all sure about this.

PS: I know this is about console/engine, but I think we will see the same here.

[CharliePoole]

I didn't want fixed dates, so I said we would maintain them at least for six months - at your suggestion.

But maybe the inclusion of a table makes the dates seem more fixed. Maybe we should remove the table or state the dates in a "softer" way.

What is currently blocking me is the question of dropping .NET Core 3.1 and .NET 5.0 agents. See #1427 and #1428.

[OsirisTerje]

I believe the table is fine, but instead of "Retirement" it could be changed to something stating the "Supported at least until".

Dropping net 5.0 I think is just fine. People who upgraded that far, will go further.
Based on the numbers I showed above, I am unsure about dropping net core 3.1. Personally I would have dropped it, but when I see the NUnit 4 downloads, I get a bit vary about it. Could perhaps try to find some general info on how much 3.1 is actually used.

[CharliePoole]

I'll do that and cancel my PR for dropping 3.1.

My own thoughts: people need a reason to upgrade, some feature they want to use. What would you see as the big motivating feature to cause people to want to use NUnit 4? What was the logic behind using .NET 6.0 rather than .NET Standard 2.0? I haven't been following it too closely, but my impression is that dropping platforms and classic asserts are the two main changes. That's OK as preparation for some other leap forward but is there a leap coming? FWIW, I mostly use 3.14.

[OsirisTerje]

The main reason for dropping netstandard 2.0/1 and net core 3.1 is maintainability of the source code. Max C# version for netstandard is C# 8, and for net core C# 10. There are also numerous other changes in the framework. If we were to support those version it would be even more #ifdefs around in the code, and much higher probability for errors. Staying at C# 8 didnt seem like a good idea either.
Secondary, increasing package size, with more versions.

[CharliePoole]

I'm aware of all those reasons - that's why I would drop 3.1 and 5.0 agents as well. And I'm not saying that the NUnit framework team made a wrong decision either. BUT... if you are going to measure your success by downloads, you have to have something to attract downloads and convenience of maintenance doesn't do that. That's why v2 of the engine and console were not released... Chris and I removed things and were in the process of adding attractive features before doing a release. Unfortunately, we never got there. :-(

I wasn't aware of the C# version limitation for net standard, however. That's unfortunate.

[OsirisTerje]

It is enough if we can keep things going. Easy maintenance means higher possibility for new inventions in the field. This is a delicate balance. If we focus too much of what can be done, and loose focus on keeping older stuff, that would be sad. If we do opposite, we will be stuck in just old code, and not able to invent.
I think it is just about finding the right balance, at this moment in time. :-)

[CharliePoole]

@OsirisTerje So I made that change but we still have three items in the table without dates. That will look odd, I think. Also, I'm a bit unsure, based on your comments, if we are or are not removing .NET 5.0 now.

Separately from this document, I need to know whether to scrap #1427 and #1428.

[CharliePoole]

Regarding the delicate balance... one thing that was going to help us with that was the planned addition of pluggable agents in V4. I couldn't see how to implement it while users were able to completely control how we used processes and application domains, which is what made it a V4 item. The agents become completely self-contained and for TestCentric, all I'm doing is archiving the ones that reach eol, but they are still available for users who want them.

[OsirisTerje]

That sounds great!.

Imho, remove .net 5.

Regarding net core 3.1, you know the code. If it is more complicated to keep it, then drop it. If it is just the package size, I would have kept it.
Some of the issues with keeping it though, is that the csproj is also affected, there are some properties that cant be used. But you know the code.

[OsirisTerje]

Jan. 2027 (same as MS for now, since it says "least until".

[OsirisTerje]

This is a kind of promise, so hard to say. MS ended Dec 2022, so, tend to say "Until further notice"

[OsirisTerje]

Should this be supported at all anymore, support ended in 2011.

[CharliePoole]

OK... I revised the table layout substantially and I hope I put in dates that suit. @OsirisTerje I used "after December 2024" rather than "until further notice" since it at least gives a hint that we will reconsider in some time frame. I think the use of "after" tells folks which dates are "soft" and which are "hard".

[CharliePoole]

@OsirisTerje We can keep or remove .NET 5.0 and .NET Core 3.1 independently and I don't think package size is an issue. Unfortunately, I got ahead of myself and co-mingled the removal of the two but I can redo that.