Rename packages and some assemblies for version 4.0 #1535
Replies: 11 comments 3 replies
-
I've not thought much about this, so this is my initial thoughts/concerns:
That being said I don't use NUnit at work (and only a little at home), so I don't think you should put too much value on my comments. I think some of the other users depends much more on NUnit than I do. |
Beta Was this translation helpful? Give feedback.
-
As @mikkelbu says, having the version number as part of the name, breaks the possibilities for upgrades, and in particular information about the presence of an upgrade. Having the version number in the name, as we did for NUnit3.Testadapter which is now in version 4, is something I'm still regretting we did. And others are confused also, that NUnit3 adapter can be used with NUnit version 4. And if the console starts with NUnit4, does it mean it doesn't work with NUnit version 3, or only with NUnit version 4, what about NUnit version 5, which may go out next year ? Further, I don't believe others do this either, semantic versioning is a better way. Also, we do have exclusive use of NUnit, so just keeping that solves one more. |
Beta Was this translation helpful? Give feedback.
-
I also think we should stick to a non-versioned name. Changing the major number in semver indicates an incompatible change. At work all our package references are of the form |
Beta Was this translation helpful? Give feedback.
-
OK, you've all pretty much convinced me and I have updated the original proposal. Except for a few points...
By the way, in writing this my assumption was that major upgrades would continue to be as rare as they have been historically. Whether that's the plan for the future really depends on who takes this over after me. |
Beta Was this translation helpful? Give feedback.
-
@nunit/engine-team Any further comments on this? |
Beta Was this translation helpful? Give feedback.
-
Most users would just want to install the next version of a tool and don't expect to then still have the old one installed. When I run a tool from the command line, I don't know what version I have, nor do I care. |
Beta Was this translation helpful? Give feedback.
-
@manfred-brands In almost all upgrade cases, I'd agree with you. But...
|
Beta Was this translation helpful? Give feedback.
-
I had partly typed up a response when @CharliePoole replied and has answered a few questions already about historical reasons :) I agree about minimizing friction during upgrade. Having to change all scripts to target a new executable is one kind of friction too, but perhaps a lesser one. Is there an issue which tracks the discussion leading to including the version number previously? I'd be curious to understand the decision making process at the time |
Beta Was this translation helpful? Give feedback.
-
@stevenaw I hadn't looked at that old thread for a few years, unfortunately. IIRC I kept the 4 in the name to make it easier for me to work on two versions at the same time without getting overly confused. I think the time is right to settle on the names we will use going forward. It seems like there's a preference to remove the major version number from the assembly name. If we do that, we end up with the following names used to execute each runner.
This leaves only one name with a version as part of it, the name of the chocolatey package. I simply don't know any way to avoid this since Chocolatey doesn't support installation of multiple versions of a package. |
Beta Was this translation helpful? Give feedback.
-
Suggest the name is suffixed with the version in a way that makes it obvious it IS the version. E.g. NUnit.Console-4.1 |
Beta Was this translation helpful? Give feedback.
-
Thanks for all the input. Since so many conflicting ideas are included in the thread, I'll summarize the conclusion...
See issue #1149 for follow-up. |
Beta Was this translation helpful? Give feedback.
-
Given that 4.0 will be breaking, I think it makes sense to start adding "4" to many of the package names:Packages
NuGet
Two options here. I prefer "NUnit4" provided we can get exclusive use of that prefix from nuget.org.NUnit4.ConsoleRunner OR NUnit.ConsoleRunner4NUnit4.ConsoleRunner.NetCore OR NUnit.ConsoleRunner4.NetCoreNUnit4.Console OR NUnit.Console4NUnit4.Engine OR NUnit.Engine4NUnit4.Engine.Api OR NUnit.Engine4.ApiChocolatey
MSI
NUnit4.ConsoleNOTE: We no longer have an msi package.Zip
NUnit4.Console.ZipNOTE: We no longer have a zip package.Assemblies
nunit4.engine.dllnunit4.engine.core.dllnunit4.engine.api.dllnunit4-agent.exenunit4-agent-x86.exe@nunit/engine-team This is a big deal for users, so I'd appreciate your comments, particularly if you see any problems!
Beta Was this translation helpful? Give feedback.
All reactions