Hi, thanks for posting.

This was, actually, the original design of the V1 licensing system. The idea was to roll features into the major versions, then do minor updates for fixes and some of the smaller compatibility improvements.

Unfortunately, it turned out to be unnecessarily expensive to license the product in this way. Every day my inbox would be full of people asking for dates on the major releases (which I couldn't accurately commit to) because they wanted to make sure their license would support it when they purchased. The need to have a branch of the code for V1 while doing major development in V2 also carried a significant technical cost.

Much worse was the difference between a 'feature' and a 'bug fix'. This sort of thing becomes very subjective with such an integrated product. For example, if NUnit introduces a small change to its API (as was actually the catalyst for this bug), is it a fix, or is a feature? Most people would probably want to consider it a fix, so they don't need to shell out $$$, and yet it wasn't something that I could have ever predicted when developing the version they're stuck with. With the licensing model you're suggesting, every code change needs to be categorised. This means constant battles over whether it's an 'NCrunch bug' or a 'Something else bug' or a 'Compatibility improvement'. In the end, it actually shouldn't matter, because the problem should just get fixed and we all move on.

By comparison, the current licensing system is much better. Releases can be smaller and more incremental, so people get features faster. There is no uncertainty around the release dates of major/minor versions because both of these things are treated the same way. Development of the product is much easier now, and everyone knows where they stand.

I also feel this is a much more generous licensing system than others employed in the industry, where the whole product will shut down as soon as your subscription expires.

Something else to consider is that if you choose not to update your NCrunch license but you do choose to continue to use the latest tooling (i.e. VS, test frameworks, etc), it's really just a matter of time before you need to upgrade NCrunch. All of these other projects are moving at breakneck speed and without a new NCrunch build every month or two, things tends to just break and get left broken.

In your particular situation, downgrading to NUnit V3.2 and NCrunch v2.23 should get you back into a functioning state. Note that the v2.25 fix is only needed if you are using NUnit V3 with theories. If you aren't, there isn't really any reason to upgrade yet.