Add single step mode

[thislooksfun]

This is an optional mode where the version number will only be incremented by the minimum possible amount, regardless of how many underlying commits there were. For example, assume the last release was v1.2.3 and your commit log is as follows:

fix: ...
feat: ...
fix: ...
fix: ...

If single_step is false (the default), this will result in the generated next version v1.3.2. Setting single_step to true, however, will result in the version v1.3.0.

This is useful if you want to bundle multiple changes into a single release without it looking like versions have been skipped. For example, doing a major refactor could result in multiple breaking changes being committed separately, which could then result in the major version being bumped from, for example, 2 directly to 5, which could confuse consumers as to where versions 3 and 4 went.

---

Notes:

• Since this change defaults to false, it is backwards-compatible.
• The code in AnalyzeCommitsAction::is_releasable is not the cleanest, as making it more readable ironically caused the code complexity metric to complain.
• Setting single_step to true locks RELEASE_LAST_INCOMPATIBLE_CODEPUSH_VERSION to 0.0.0, as it is no longer feasible to calculate due to there no longer being intervening versions. If there is a decent workaround for this that I just didn't think of, I'd happily implement it.

[xotahal]

We had a conversation about this one already - https://github.com/xotahal/fastlane-plugin-semantic_release/issues/11

I am still a little bit against this. I know I mentioned that we could have such a parameter but I feel this is not a good approach. Why keeping numbers low is better than having "pure" commit based deployment? Users don't care if there is 1.3.0 or 1.3.2. They don't even know what "method" you are using to deploy versions. They could think there is a private beta 1.3.1 and they got the "public" one.

With the current approach, It can't happen that two commits would produce the same version. So it will be always the same for a specific git repo history. No matter which developer is doing the deployment and when. No emotions. That's what we are trying to achieve, right?

I just still don't know if we want to allow this or not.

[thislooksfun]

We had a conversation about this one already - #11

Ah, I had somehow missed that discussion completely.

I am still a little bit against this. I know I mentioned that we could have such a parameter but I feel this is not a good approach.

Having read through it I agree that my implementation here was naïve and self-centered. I will go back to the drawing board and make a new PR with the 3-layer ("minimal", "maximum", "locked") style discussed here. Therefore I'm closing this PR in favor of that new one.

With the current approach, It can't happen that two commits would produce the same version. So it will be always the same for a specific git repo history. No matter which developer is doing the deployment and when. No emotions. That's what we are trying to achieve, right?

That is a perfectly valid approach. However, even it has pitfalls. Technically the following sequence of events would violate that:

0. Repo is at version 1.2.3
1. Alice clones master to alice-branch
2. Alice creates a new commit fix: some bug
3. Bob clones master to bob-branch
4. Bob creates a new commit fix: some other bug If Alice and Bob deploy from their own branches here, then they would both produce v1.2.4. If they merge to master first, then yes it is deterministic—technically—but if you only ever deploy from master from a single source then why does the next version matter at all?

I just still don't know if we want to allow this or not.

In your own words, "there are as many opinions as there are people", and there are also as many people as there are options. While I agree that there should be a limit to how many new features should be added—the line needs to be drawn somewhere—I also believe that core assumptions like this one shouldn't be forced on people (for example, see #24—a similar argument could be applied of the form "well why would you want different commit format? This is the one it ships with, why can't people just use that one?"). You can set defaults to whatever you like, but ultimately the end user will use it how they want, and I personally would rather not reinvent this particular wheel.

I hope my comments here made sense. If you ultimately decide against implementing this feature, then that's your decision and I'll just keep my own fork, but I know others want this feature too, and I always prefer to use the real release to keep up with bugfixes.

[xotahal]

@thislooksfun Thanks for the comment. Let's do that then. It makes sense. I've never been completely against it. It just feels to me that we are bringing the emotions back and that's what I didn't want to do. Could you ping me on twitter? I want to discuss with you something. https://twitter.com/xotahal