Legacy NUnit Projects

[CharliePoole]

As has been discussed several times here and on various issues (see https://github.com/nunit/nunitv2/issues/43#issuecomment-325520091 for example) I have been looking at doing "something" with the legacy NUnit Software. At this point, I know what that "something" is, at least in general outline.

I'm creating this issue to give the Core Team a chance to point out any problems that my plans might cause, suggest any changes and - if necessary - consider what the NUnit Project may want to do in light of them.

So...

I have come to feel that support for V2 is still needed in many quarters. The project has decided to limit support to helping people migrate to NUnit 3. That's a reasonable decision.

My thought is to find out if there is enough need for V2 to justify some new work to fix bugs. If it's sufficient, I may offer paid support through NUnit Software. Frankly, one reason that it would be paid is that if I'm doing programming for free, I prefer it to be on new work, not old.

However, as you will see below, I also have a reason to do some work with the V2 source, which relates to the nunit-gui project. Without further ado, here is my back-of-the-napkin plan:

1. Fork NUnitV2 to my own account for the initial work. (Done)
2. Modify the key file so it will build on later versions of VS. (Done)
3. Review some outstanding bug fixes and apply them if they make sense.
4. Release a new package at the 2.6.5 level to mark a plateau. NOTE: This could either use the same names as NUnit or possibly use nunitv2 for clarity. What does the team think best?
5. Take the Gui project and rewrite it to use the NUnit 3 engine. Release an NUnit 3 GUI that looks pretty much like the old NUnit Gui. This is not the same gui that is being worked on now but it will get something out for people to use very quickly.

Thus, there are two outcomes for me. I have a 2.6.5 release, which allows me to gauge interest in NUnit V2 support and decide whether to go further. Additionally, I have a quick and dirty gui for people to use while we redirect our gui work to use other technologies, as we are planning to do.

IF you see anything in this that potentially causes problems for the NUnit Project, please speak up!

[rprouse]

All sounds good to me. If you release 2.6.5, I think that you should do it under the same name and NuGet package feed. I think that will give you the most accurate gauge of interest as it will be an easy upgrade for existing users. Otherwise, users will have to uninstall 2.6.4 and install your new package. I also expect that a new package will be difficult to discover, further lowering the potential.

NUnit 2.6.4 still has fairly high usage, it will be interesting to see how many people will upgrade. The 6 week running stats are at https://www.nuget.org/stats/packages/nunit/?groupby=Version

Version	Downloads
3.9.0	244,199
3.8.1	341,664
2.6.4	174,055

The tide has definitely turned in favor of NUnit 3, but there are still a lot of NUnit 2 users. It will be a very interesting experiment to see how many of those would upgrade to 2.6.5. If it is high, then the barrier to upgrade is probably higher than we believe.

[CharliePoole]

Interesting way of looking at it... release as a means of measuring usage. 😄 I'll do that.

[ChrisMaddock]

Sounds good to me - will be interested to hear about take-up.

[CharliePoole]

I'm ready to work on a release with a number of fixes in place. Let's tease out the details of this to be sure we're on the same page...

1. Code is now at charliepoole/nunitv2. Changes are almost all related to obsoleting various things and adding in some of the replacements for what is marked obsolete. For example, Is.StringMatching is obsolete so Does.Match is added.

2. I'll move it to NUnitSoftware/nunitv2 and create the release there.

3. I'll release all the same files as https://github.com/nunit/nunitv2/releases/tag/2.6.4 with the exception of the docs and the .NET 1.1 builds. We no longer have the ability to create release docs for download and the changes are minimal. For .NET 1.1, I don't see any point and I have introduced code that won't compile under it anyway.

4. For the nuget files, I'll add them to the NUnit feed.

Does this make sense to everyone?

If there's enough takeup to go further, I expect I'll create a separate nuget feed and put the documentation online. I'd then do a 2.7 release for the purpose of completely dropping a few things (mocks, pnunit) and probably create a chocolatey feed for the executables.

I've also sketched out an entire compatibility reporting mechanism, which can save a list of issues found while the tests were executed. I want to find out if there's really interest before spending more time on it.

If there is not sufficient takeup, then you might consider merging my work into the nunit repo, so it's all in one place.

[rprouse]

All good. If you don't mind, I would like to sync the nunit repo after you do your initial release so that people don't get confused. Or, should we archive the nunit repo? Or update the readme to point to your copy?

[CharliePoole]

At this point, my repo is treated as a fork of the nunit repo. So it's possible for me to do a PR to merge it all. In fact, I've had to do my merges manually to get them into my master up to now.

Note that nunitv2 is already marked as archived.

The problem I see is that we may want to do two conflicting things, depending on how this turns out.

1. Put out one or two more releases of nunit/nunitv2 and then forget about it.

2. Continue to support V2 as NUnitSoftware/nunitv2.

SO it seems we want to only do stuff right now that's compatible with both outcomes.

Not 100% sure what that is, however. 😄

[CharliePoole]

@rprouse We can continue this discussion after your ski vacation. I'll put a comment here to summarize whatever I do in the next few weeks.

[CharliePoole]

Closing this since no further action seems needed.