Add single step mode #23
Conversation
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.
|
We had a conversation about this one already - #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 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. |
Ah, I had somehow missed that discussion completely.
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.
That is a perfectly valid approach. However, even it has pitfalls. Technically the following sequence of events would violate that:
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. |
|
@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 |
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.3and your commit log is as follows:If
single_stepisfalse(the default), this will result in the generated next versionv1.3.2.Setting
single_steptotrue, however, will result in the versionv1.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:
AnalyzeCommitsAction::is_releasableis not the cleanest, as making it more readable ironically caused the code complexity metric to complain.single_steptotruelocksRELEASE_LAST_INCOMPATIBLE_CODEPUSH_VERSIONto0.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.