Version number for next release

[rouke-broersma]

Since the last update a number of contributors have contributed new mutators. In the past we have had some discussion around the introduction of new mutators and whether or not this requires a new major version.

The argument for a major version update is that users rely on the mutation score for failing pipelines or blocking release gates, and the introduction of new mutators would block them when there are no significant changes on their side, except from updating stryker.

The argument against a major version update is that we are not technically breaking anything about the interaction with stryker. We are introducing new features, that point out a lack in mutation coverage you already had but could not see.

To avoid unnecessarily annoying our users we would like to take a short poll to decide on the next version number. Especially because it's not just one but rather multiple new mutators at the same time. This discussion also serves as a pre-announcement that these new mutators are coming.

@psfinaki I know you'll have an opinion :)

[richardwerkman]

We even release bugfixes that introduce new mutations as they were previously rollbacked. We don't mark them as major releases. Of course a new mutator introduces a lot more new mutations. But I'd argue a major release should be reserved for actual configuration changes and not for number of mutations.

[psfinaki]

I'd say ultimately it doesn't matter that much as long as Stryker doesn't do backports and security fixes for random versions :)
Since there is no capacity for this, Stryker could just have versions 1, 2, 3, 4, 5, and so on, or maybe reserve major version updates for "very breaking" changes. I think the current naming scheme more relies on the "t-shirt" size of changes.

So with that in mind, the recent changes feel "big" to me so I'd expect a new major version. But much more important is to just indicate what's changing and empathize that "this might affect your mutation scores".

[nicojs]

I would probably release it with the mutators inactive by default (for example, using your mutation levels stuff). Then the next time the breaking change train comes along you can update it to include these mutators by default.

Pro tip: You can also create an issue to not forget it and link that to the new milestone in GitHub (that's how we do it in stryker-js)