Repository navigation
create a dev bump straight after a normal bump #662
Description
Activity
I think
cz bump --devrelease 0should not work, because the new increment is not specified. But I think doing eithercz 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?
Reacted by Wei Leeoh, 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
--forceis the context, force what? people can expect different behaviours from itReacted by Wei LeeI 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)
Reacted by Wei Lee👍 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 pushIn 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?Reacted by Santiago Fraire Willemoes and Rambaud Pierrickanother 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.
Reacted by Simon
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
--devreleaseoption of thebumpcommand 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
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)