The release cadence is for me not a fixed goal, but more like a guideline to help us decide when to release something. My stating minor versions 4 times a year (which in reality have been more like 2 times a year for the last 3-4 years), is more like saying two things:

1. Let us release when we have resolved more than 20 issues.
2. Let us try to release 4 times a year, which means, let us try to fix 80 issues per year.

We have over time reduced the backlog, I believe we started at around 500 issues, and now we are down to around 250. So we're actually eating them slowly, but consistently - which is good.

A major version to me is :

1. It include breaking changes, we MUST add that to a major version
2. It includes large changes, even not breaking, they do deserve a major version due to their importance and possible impact.

Other new features can simply go into a minor release, together with non-critical bugs.

Critical bugs goes into a patch release, but we try to avoid that.

Now, if it all was this easy, - it is not ------ read on:

Bugs are of two categories:

1. The implementation of a functionality is imperfect or faulty. The design and specification is correct, but code doesn't implement the specification correctly. This is a normal straightforward implementation bug. The intent is agreed upon, and the code deviates from it. These are usually localized, easier to test, and safer to fix because the “correct” behavior is already defined.

2. The functionality is wrong, either the design itself, or the specification is wrong. This is a "specification bug" (or design bug). The system behaves as designed, but the design itself is flawed. They also risk breaking consumers because the “wrong” behavior may already be relied upon.

One important addition is that the boundary between the two is not always clear. What looks like an implementation bug can reveal an ambiguity or gap in the specification. In that sense, many actual bugs are partly both: the code made a choice where the spec was unclear.

Although most of our bugs is category 1, we do have several of category 2.

A category 2 bug may break the user, but the user is actually having a faulty test. They may have worked around it, or adjusted their surroundings to match the perceived functionality we have.

To us, we need to figure out: Is this a breaking change that require us to add it to a major release? Or should we state that this is a specification/functionality bug, and we simply fix it as a minor version change?

The last one I noted of this case is the one @manfred-brands raised as #5221 . We allow "useless combinations" as described there, and when we fix this (in a minor version update), the user who have done such stuff will have their code breaking. (Currently the analyzer will catch a lot of these, so people have been warned - in this case).

Imho, this is a case where I believe we should announce the fix, but keep it in a minor version - if doable. Mostly....... Users depends on behavior, not intent, so if the analyzer haven't warned them, and the design is non-obvious, then we might have to make it into a breaking change, thus a major version.

At our work we have 100s of repositories that all use semver ranges for referenced nuget packages, like "[3.14.0, 4.0.0)".
This allows for bug-fix and feature updates and preventing breaking changes.
About half of them include a .NUnitExtension packages that a.o. have dummy implementation of functionality that can be used by users of the library to mock the real thing to be used for their own tests.

As upgrading to a new major version is a lot of work we need to be convinced that moving to a new version is worth it.
For NUnit 4 we love the updated reporting which shows the actual code being tested, but it hasn't been enough to switch.
A type safe API would be worth it.

Having said that, I'm against updating a major version for non-breaking changes.
We had to remove the upper range for references to MS libraries because they number them based upon the SDK they are released with.
Like System.Collections.Immutable version 8.0 and 10.0 but don't have breaking changes.

So if we can introduce features or "correct" the API a minor version increase is preferred.
We have done those latter ones when we typed some of the EqualTo overloads, but without removing the original object overload.
Now IgnoreCase can only be used when comparing strings (and object), not when comparing numbers.
Similar, tolerance is only supported for numeric conversions.
We no longer can use .Seconds for tolerance for anything but Date types.

Those kind 2 changes won't affect

• any existing binaries as the original object overload still exists.
• any compilation of existing code, unless it does things that never made sense but were allowed.

When do we need a new major version.

• When we drop existing methods/classes.
  • We could not introduce CallerArgumentExpression as an optional parameter as it conflicted with the original api as they look the same in user code. P.S. I wonder if we could add them back in with an OverloadResolutionPriority to gain binary compatibility.
  • If we change our methods accepting a Func<Task> to return Task and become proper async as user cannot ignore the return value as it would not necessary execute any code.

Back to where this started.
Adding overloads for Action is non-breaking.
Adding overloads for Func<T> breaks code that previously checked a variable of that type for Null as now the Func is evaluated.
Is it breaking enough to justify a major release that is the question.

I'm happy to not ever need major versions if we can introduce features without breaking things.