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

bumping to the wrong version #928

Open
stratoss opened this issue Sep 21, 2022 · 5 comments
Open

bumping to the wrong version #928

stratoss opened this issue Sep 21, 2022 · 5 comments
Labels

Comments

@stratoss
Copy link

stratoss commented Sep 21, 2022

Describe the bug
After months of normal usage, today standard-version stopped bumping the versions normally. It is trying to bump it from 2.3.0 to 1.0.1.

Current behavior
✔ bumping version in composer.json from 2.3.0 to 1.0.1

Expected behavior
✔ bumping version in composer.json from 2.3.0 to 2.3.1

Environment

  • standard-version version(s): 9.3.1
  • Node/npm version: node v16.17.0
  • OS: Debian 11

Possible Solution

Additional context
.versionrc.js:

module.exports = {
	"releaseCommitMessageFormat": "chore(release): {{currentTag}} [ci skip]",
	bumpFiles: [{
		filename: 'composer.json',
		type: 'json'
	}],
};

git tag -l returns last tag as v2.3.0

composer.json holds the proper 2.3.0 version

@stratoss stratoss added the bug label Sep 21, 2022
@aperkaz
Copy link

aperkaz commented Oct 27, 2022

This project is now deprecated (#907).
You can check out https://github.com/absolute-version/commit-and-tag-version as an alternative.

@stratoss
Copy link
Author

@aperkaz , maybe this should be made as announcement in the README... Thank you for the information.

@blogcraft
Copy link

I have the same problem any possible work around? I have multiple CI in azure devops. And some just are stuck in 1.0.1 and cant get to see why.

@kaotika
Copy link

kaotika commented Sep 18, 2023

I had the same issue on gitlab and the solution was simple: adding GIT_DEPTH=0.

By default the runner clones just the last 20 commit messages and if you have more than this, the calculated SemVer wasn't correct. Most likely most CI providers use something similar to reduce the time to fetch the git log.

@pedrosanguineti
Copy link

We had the same issue in azure devops, and as @kaotika says, it was related to the depth. In Azure Devops, after September 2022, newly created pipelines have shallow fetch enabled by default and it's configured with a depth of 1. We disabled it and everything started working as intended.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

5 participants