Standard-version: How can I avoid the inclusion of all previous changes on my changelog?

[Oscarz90]

I having a problem with the changelog generations, every time that I release a version, the changelog include all the previous versions' changes, does it suppose to include just the last changes from the last git tag ??

[danfoy]

I'm having this issue also.

[eemeli]

Are you perhaps using a non-standard tag prefix that isn't being detected correctly? You could try running this in you project's directory:

npx git-semver-tags --tag-prefix foo

with foo replaced with whatever's appropriate for you. The output should be a list of your release tags.

[danfoy]

Thanks for the suggestion @eemeli

That doesn't output anything in my repo 🤔 but standard-version is generating v#.#.# git tags that show up with git log --oneline --tags, and I'm using the standard (angular-style) titles for my commits. It seems to be detecting the titles fine because it sorts them into the headings I've defined in package.json just fine (and fails if I forget the semicolon in the title).

But then it sticks every commit I've ever made into each version bump.

[janhoogeveen]

Seeing similar behavior in our repo where everything from 1.3.3 and upwards gets compared to 1.3.3.
I get the idea that v1.4.0 and v1.5.0 are not recognized as valid tags, but I wouldn't know what's wrong with them.

➜ git tag
v0.1.0
v0.10.0
v0.11.0
v0.2.0
v0.3.0
v0.4.0
v0.5.0
v0.6.0
v0.9.0
v1.0.0-alpha
v1.0.0-alpha.1
v1.0.0-alpha.2
v1.1.0
v1.2.0
v1.2.1
v1.2.2
v1.2.3
v1.3.0
v1.3.1
v1.3.2
v1.3.3
v1.4.0
v1.5.0
v1.6.0
v1.6.0-alpha.1
v1.6.0-alpha.2
v1.6.0-alpha.3

vs

➜ npx git-semver-tags
v1.6.0
v1.3.3
v1.2.2
v1.2.1
v1.2.0
v1.1.0
v1.0.0-alpha.2
v1.0.0-alpha.1
v1.0.0-alpha
v0.11.0
v0.10.0
v0.9.0
v0.6.0
v0.5.0
v0.4.0
v0.3.0
v0.2.0
v0.1.0

CHANGELOG.md

## [1.6.0](https://github.com/project/project/compare/v1.3.3...v1.6.0) (2020-08-05)
## [1.5.0](https://github.com/project/project/compare/v1.3.3...v1.5.0) (2020-07-31)

Running npx-semver-tags

[gtokman]

@danfoy seeing similar behavior with the same commits showing up in my releases.
Running ➜ git tag -l |grep v

v4.1.0
v4.2.0
v4.3.0
v4.4.0
v4.5.0
v4.6.0
v4.7.0
v4.8.0
v4.9.0

but running npx git-semver-tags --tag-prefix v I see nothing.

[eemeli]

@danfoy Conventional-changelog tools use git-semver-tags to determine what the latest release is, and builds the changelog based on that. The current version is read from package.json, if possible. The git tags are written directly. Put together, this means that it's entirely possible for just one part of all that to fail independent of the others. :/

Another thought: Could it be that your tagged releases are not direct ancestors of your HEAD commit? In any case, it might make sense to see if conventional-changelog/conventional-changelog#588 is the same as your issue and/or file a bug report in that repo.

[DuncanFaulkner]

I'm having similar issues with standard version, I use git-cz (commitizen) and standard version.
The thing is the web frontend is not the (final) release, we have a number of other packages that eventually form a release.

I create a branch, make my changes and then run npm run commit this runs the commitizen and does a get add and generates the commit message. After this I run npm run release (on the same branch) this updates the changelog and version number and it's at this point it duplicates previous changelog entries.

Most of the time I have to run npm run release -- release-as patch as it always wants to bump to the next major version for some reason.

According to this article: Automate JavaScript project versioning with commitizen and standard-version)

I need to run npm run release on the master branch after a merge, we use develop instead of Master, and we have disabled all developers committing into develop.

This duplication is becoming quite frustrating now as an issue. WHY does it do it and is there a way to stop it?

[AThiyagarajan]

I'm having similar issues with standard version, I use git-cz (commitizen) and standard version.
The thing is the web frontend is not the (final) release, we have a number of other packages that eventually form a release.

I create a branch, make my changes and then run npm run commit this runs the commitizen and does a get add and generates the commit message. After this I run npm run release (on the same branch) this updates the changelog and version number and it's at this point it duplicates previous changelog entries.

Most of the time I have to run npm run release -- release-as patch as it always wants to bump to the next major version for some reason.

According to this article: Automate JavaScript project versioning with commitizen and standard-version)

I need to run npm run release on the master branch after a merge, we use develop instead of Master, and we have disabled all developers committing into develop.

This duplication is becoming quite frustrating now as an issue. WHY does it do it and is there a way to stop it?

@DuncanFaulkner I am also having the same issue.

npm run release release always bumps 1.5.0 to 1.6.0 instead of 1.5.1.
My change logs are also has duplicate content.
My commit has only fix type or chore type commits

[mason-kanpai]

Run this and make sure your tags are there. I had similar issues and my changelog had duplicated changes.

git log --decorate |grep tag:

Then, I manually created missing tags and issues were fixed.

git tag -a v1.5.1 commit_SHA -m 'chore(release): 1.5.1'

[DuncanFaulkner]

thanks, I've set it to skip tags, I check my feature branches into develop at some point in the future when we pull all the other packages (Middleware, and low level C++ packages etc) I think we either merge into master and create a release from that or we create a release branch off of develop and make a release from that (I don't get involved with that part). At the creation of the release each project frontend, middleware etc.. then gets a tag. Which is why I was skipping tag creation. plus I can't push into develop only to a feature branch, and then a PR into develop.

I've kind of got it working but it's more of a hack and not how it should work, I think standard-version needs to become a bit more flexible in how it allows users to use it.

[huksley]

I understand now why it happens 👍 Your tag has no relationship with the HEAD tree in the current branch. Best would be removing these tags (which npx git-semver-tags does not show) and recreate them as @mason-kanpai suggested in the HEAD

[Oscarz90]

I understand now why it happens Your tag has no relationship with the HEAD tree in the current branch. Best would be removing these tags (which npx git-semver-tags does not show) and recreate them as @mason-kanpai suggested in the HEAD

Guys! this was my mistake, I made a release and git generates a tag, but I made that release on another branch, after I merge that branch to master that generated tag points a commit on another branch (usually I delete branches after merging them), for that reason when I tried to make another release the lib tried to find the last tag (and for that reason after find any tag, it includes all again to our changelog), but that tag in resume didn't exist anymore (or exists in another branch but not master branch), the fix for me was simple we could release versions directly on master, o create a branch make a pr and there releasing the version but after merge that branch to master we should create a tag (create a tag sited on master branch) with the specific version (I did the git tag on my local after pulling changes and push the new tag) and that is how we cand avoid the inclusion of all previous changes on my changelog, tag are super important for this!!!!!