0.17.0-beta.1

Our prior parallel version logic allowed reckon to increment by the requested scope a second time in order to avoid a parallel
version. However, if that version is also in the parallel branch, it would fail saying the version was already claimed.

In the new logic, if we bump the target normal in order to avoid a parallel version and that version is still in the parallel versions
list, we increment by a higher scope (i.e. by MAJOR if they requested MINOR or by MINOR if they requested PATCH).

This may resolve many of the bugs we had with parallel version handling.

The two unintuitive parts are that it may still not increment as far as someone wants in some cases. And in others someone could be surprised that we incremented by a higher scope than they asked for.

To deal with the latter, we may want to consider making a distinction between "soft" and "hard" scopes (i.e. did they explicitly ask for the scope or did it get inferred). This was clearer in the past, when "inferred" really only meant no input from the scope calc. However, with the new commit message scope calc, that's really more of a "soft" scope request than an explicit one. It's trickier because to the Reckoner there's no difference between commit message scope calcs and explicit user-requested scope calcs.

Breaking Changes

• #181 results in cases where reckon may increment with a higher scope than the user provided in order to avoid parallel versions. In past versions, this would have failed instead saying the version was already claimed

Enhancements

• None

Fixes

• #180 Parallel branch with two released versions will cause failure due to claimed version

Deprecations

None

Compatibility

Tested against the following versions.

Java Version	Gradle Versions
11	7.0.2, 7.5.1
17	7.3.3, 7.5.1