commitizen
commitizen copied to clipboard
create a dev bump straight after a normal bump
Description
In projects I'm working in (the ones that are not yet using commitizen
) maintainers are bumping a dev version straight after the bump of a new one. That ensures that the version number of the current master/main branch is not the same as the latest release.
I wanted to use the new --devrelease
option of the bump
command for that purpose but as there are no changes to report since the last version, it's not working and the bump fail.
Do you think it would be doable or is it a workflow that you don't want to cover?
Steps to reproduce
cz bump
cz bump --devrelease 0
Current behavior
bump fails
Desired behavior
bump succeed (bonus point if nothing is written to the changelog file)
Screenshots
No response
Environment
cz version: master (as I still have an issue with my name convention and didn't find the time to work on #463)
I think cz bump --devrelease 0
should not work, because the new increment is not specified. But I think doing either
cz bump 0.2.0
cz bump --increment minor
cz bump --increment minor --devrelease 0
should work. This could force a bump, I'm not sure if there's a problem with this that we are missing. @Lee-W do you have any thoughts on this?
oh, I didn't know I could force the increment. let me check this afternoon
No, you can't haha sorry for the misunderstanding. I was just thinking whether it should be possible to force a bump or not.
The alternative is to have something like --force
.
Edit: The problem with --force
is the context, force what? people can expect different behaviours from it
I was reading PEP 440 to better grasp what is a "dev" release and as a starter I think "dev" should behave differently from a normal release. e.g. should not trigger the changelog update. In fact, it's an internal feature use by linux packaged lib to create continuous packages and test the installations right ?
In this context, you should be able to do a dev release whenever you need even if you just pushed "style" commits/nothing.
But without commits, if you use commitizen, what kind of semver version would you get?
Add "dev" to whatever is set in the config (apparently, it can be added on top of anything, pre-release, post-release etc...) ?
Hi @12rambau , I've tested with the following commands and succeeded. May I know what the error you encountered is?
mkdir test
cd test
git init
cz init
touch test_1
git add test_1
cz c
cz bump
touch test_2
git add test_2
cz c
cz bump --devrelease 0
I got an "increment" error when bumping the dev release, maybe it's related to the automatic changelog (let me check from dummy repositories)
👍 on this request. In our workflow we have the following flow:
- during a release we bump (for example): 0.1.1.dev -> 0.1.1
- after the release we want to bump 0.1.1 -> 0.1.2.dev (without any commit in between) - we use it to distinguish between released versions and development versions.
I apologize for not being more consitent in the follow-up of my issues but release problem don't appears so often.
So I checked without the changelog that's the same. I cannot create a dev release without creating a dummy commit in between. Problem is our workflow in pydata-sphinx-theme is exactly the same as the one described by @kptkin. what i would like to do is:
cz bump
git push
git push origin <tag_name> # trigger the gh action
cz bump --devrelease 0
git push
In order to get my version set to dev0 right after the publish on pypi.
Is it something you would like to implement or is out of scope ?
I think I'm ok with this feature. maybe something like cz bump --devrelease 0 --empty
? @woile what do you think?
another situation where "empty" could be useful is the following:
- I did push something to pypi
- I realize I mixed some file and uploaded the wrong tarbal (shit happens)
- I cannot keep the same version number as it's locked on pypi side
- I need to update version number without any commit as I will simply reupload the correct files
+1 for this. Are there any updates on the PR / general topic?
There's an open PR. I'll take a look today.