Can we move rapidly to V4 with Breaking Changes only?

[CharliePoole]

I mentioned this in passing in #860 and I'm creating this issue to track the idea.

IMO, because of NUnit's history, we're somewhat stuck in the idea that major version changes are extremely rare and incorporate a lot of new features all released at once.

But in semantic versioning, it's the breaking changes that cause a major version change.

So, provided we can determine in advance all the things we plan to break, why not just do a 4.0 release that has only the breaking changes plus a minimal set of features and enhancements that are actually required for us to live with the breaking changes?

If we did this, we would be able to simplify the code base and hopefully move ahead more rapidly with new features, unencumbered by backward compatibility with features we intend to remove.

FWIW this is what I've done with the TestCentric GUI. I felt I was being slowed down by legacy stuff, which I had to support in 1.5, 1.6, etc. so I defined a new 2.0 with 3 breaking changes. In my case, they were

• Removal of Domain Usage
• Removal of InProcess execution
• Possible removal of some agents, facilitated by making the agents pluggable extensions.

Could we do something similar for the console and engine?

[runehalfdan]

As long as the console-runner can run side-by-side with older version, I don't really see a problem.

One legacy-thing that we still need is v2 result output. Bamboo build server still don't support Nunit v3 output format, and they don't seem willing to support it either:
https://jira.atlassian.com/browse/BAM-18336?error=login_required&error_description=Login+required&state=35124e61-0d30-4858-a213-6eebc3d25142

[CharliePoole]

@runehalfdan Yes, I learned this researching a recent issue. Bamboo is the major sticking point, which keeps the V2 result writer alive.

As the maintainer of that extension, I'm in a philosophical quandary. Am I supporting users by continuing to maintain the extension or am I really just saving money for a commercial company by enabling them to avoid supporting NUnit 3 output? I haven't resolved that yet. 😄

[ChrisMaddock]

I absolutely agree with this, and have thought the same recently. I think it's probably the only viable way we'll get a 4.0 release out.

I also like to consider decoupling the engine and console version numbers. Given the userbase of each product, I think we can afford to make breaking changes in the engine much more readily than the console, which could unstick development. Needs some thinking through as to how we make sure engine development remains accessible however - given we're so used to using the console as the test runner!

[CharliePoole]

@ChrisMaddock Maybe that's a new 4.0 issue.

It seems easy enough conceptually. Assuming you want to keep one solution, we could just use nunitlite to run engine tests... that's what I do in the GUI.

Should we next identify all the breaking changes?

[CharliePoole]

Is a Zoom planning meeting possible?

[ChrisMaddock]

Can do - will reply to a few of your emails tonight and let's see where we get to! I definitely think identifying the breaking changes first is a good way to go.

[CharliePoole]

We have moved ahead with this idea and there is no further action to take, so I'm closing.