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.
Will run this by the users and see what they think.
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.
Will run this by the users and see what they think.
Fixes https://github.com/ajoberstar/reckon/issues/180 Related to https://github.com/ajoberstar/reckon/issues/102