conventional-changelog/standard-version

Change version from 0.x.y to 1.x.y

dpergarc opened this issue · 7 comments

dpergarc commented

Hi there,

I am trying to upgrade the changelog versions from what I consider the beta ones to mayors (that is to say, from 0.x.y to 1.x.y), but I am not able to do so, instead I am obtaining the minor version. You may find the example I am following below:

  • 0.0.0 -> fix, feat, others... -> "npx standard-version" -> 0.0.1
  • 0.0.1 -> fix, feat, others... -> "npx standard-version" -> 0.0.2
  • 0.0.2 -> fix, feat, others... -> "npx standard-version" -> 0.0.3
  • 0.0.3 -> fix, feat, others... and BREAKING CHANGE -> "npx standard-version" -> 0.1.0

Which steps should I follow in order to make a double BREAKING CHANGE so I can have 1.x.y?

Thanks in advance, looking forward to hearing from you.

Kind regards.
Daniel.

drabodan commented

To do this, you need a commit that contains BREAKING CHANGE: in the footer, or ! after the type/scope

https://www.conventionalcommits.org/en/v1.0.0/#examples

Also, you can specify the version directly - https://github.com/conventional-changelog/standard-version#release-as-a-target-type-imperatively-npm-version-like

dpergarc commented

Hi drabodan,

Thank you very much for your reply! The first option you mention is the one I would like to follow, but I am afraid it does not work (see the picture attached that shows the complete example).

image

The second choice is not good since, in the nearby future, I have the idea to integrate it with a CI/CD gitlab process already developed.

Am I doing something wrong? Is there anything I am missing?

Thank you very much beforehand, looking forward to hearing from you.

Kind regards.
Daniel.

drabodan commented

In this case, I can only recommend debugging and researching to understand why the final version is not calculated as expected.

Based on the code, the research should start with this logic - https://github.com/conventional-changelog/standard-version/blob/master/lib/lifecycles/bump.js

dpergarc commented

Hi dradoban,

Thank you again for your reply. So, in few words, it is actually a standard-version bug, right? If true, I would like to know if there is some sort of alternative work-around to keep going in the meantime, otherwise, I will have no option that to debug as you have suggested... but it would be when I have some free time (unfortunately, that case is not very usual nowadays).

Looking forward to hearing from you.

Kind regards.
Daniel.

drabodan commented

It is not necessary that there is some kind of bug, and even if there is an bug, it may not be in the standard-version itself, but in the dependency. This you can understand in the process of research.

Just for information - I have not reproduced any problems in this behavior. Also, just in case, I note - I'm not the support in this repository, I just "passed by" and decided to try to help you.

Of course, it's not unbelievable that software can have bugs, and it's also completely normal when you use open source products that you spend your time figuring out the problem if you encounter some kind of complexity. Ideally, you create a PR in a repository with a solution, repository owner accepts it and no one else encounters this problem, and the product gets better.

If you do not have time, then you can take a look at the alternative suggested at the very top https://github.com/conventional-changelog/standard-version/blob/master/README.md. Also, don't forget that standard-version is deprecated.

Good luck with your work and have a nice day.

dpergarc commented

Hi drabodan,

Yeah, do not get me wrong, I was not complaining about if there are bugs... in fact, I consider this a great tool, since the integration with my code only took me few minutes.

Ok, I will take a look to the current standard-version alternatives.

Thank you very much.

Kind regards.
Daniel.