Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

major: Allow incrementing by higher scope than requested #181

Merged
merged 3 commits into from
Aug 14, 2022
Merged

Conversation

ajoberstar
Copy link
Owner

@ajoberstar ajoberstar commented Aug 14, 2022

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 #180
Related to #102

@ajoberstar ajoberstar self-assigned this Aug 14, 2022
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 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 #180
Related to #102
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Wrong insignificant tag generated when using maintenance branches with patch releases
1 participant