NUnit lifecycle policy #4424
Replies: 4 comments 1 reply
-
I feel that our updates should track the lifecycle of the frameworks we are targeting, https://learn.microsoft.com/en-us/lifecycle/products/microsoft-net-and-net-core. My experience is that companies and developers that aren't keeping their projects up to date aren't updating their NuGet packages either. I've also had to install older unsupported frameworks to make contributions to NUnit. I can do that on my personal computer, but I prefer to not do it on my work computer. |
Beta Was this translation helpful? Give feedback.
-
Both at my old company and at my existing company we have tried to update nuget packages as often as possible, but in both places we have also been "stuck" on old frameworks due to a lot of code and tests (i.e. updating from .NET Framework => .NET Core and updating from .NET Core 2.1 to .NET 6.0), so I think that there is a larger group that updates nuget packages, but which also are struggling to keep up with the MS release (for various reasons). For the questions:
I think we should keep the support for some time e.g. 6 months.
I think we should focus on LTS and only do the minimal wrt to STS to make tests run
I think so |
Beta Was this translation helpful? Give feedback.
-
I think @mikkelbu 's thoughts more or less mirror my own, which makes this an easy comment to write :) We update major versions when we "must" at my work, which means no less frequent than jumping from LTS to LTS as support is dropped for earlier versions. Conversely, I tend to install new frameworks on personal devices near the end of the public previews when it hits RC. I also like the idea of dropping support for an EOL runtime in the framework up to 6 months after Microsoft's EOL date elapses. Anecdotally this has seemed to align with when cloud providers drop their own support, at least if past CI failures are any indication |
Beta Was this translation helpful? Give feedback.
-
Thanks all for this; sorry for weighing in late. I think dropping support for unsupported frameworks in our subsequent major releases is a fine thing to do.
|
Beta Was this translation helpful? Give feedback.
-
Back in the days NUnit was very concerned about keeping backwards compatibility wrt to target frameworks. Only recently have we started to trim down on that.
The new Microsoft lifecycle policies with a much higher cadence also makes it harder to maintain backwards compatibility all the way.
We now have Net Framework at 4.6.2 as a minimum and .net standard 2.0 as the minimum for net core.
We have recently discussed to include .net 6.0 as a target. If we keep the netstandard 2.0 we will then have 3 different targets (up from 2) in the package, meaning we "up'it" with 50%.
We do test for a multitude of targets to ensure it works on those, but the more we keep in there, the longer the tests takes, and the more verbose output we get (as many of the non-run tests still output a lot of noise).
Going for a newer version of .net means we can also take advantage of the improvements there.
Having to support older version using conditional compiling directives are a pain. Some we must accept, but can we shorten down the list it would help.
Also see some discussions earlier in #3070 and #4416.
Comments: @manfred-brands @jnm2 @stevenaw @mikkelbu @SeanKilleen @rprouse
Beta Was this translation helpful? Give feedback.
All reactions