Arbitrary command running along the versioning

[fizyk]

I'd like to connect towncrier along bumpversion, and what I envisioned would be to run a command in the middle of the bumping version process:

1. first part of regular bumpversion: replace all versions and add changes to git
2. run towncrier to generate changelog
3. finish bumpversion with commit and tag

I want to do this specifically in this order, since What other feature I'm pursuing is to generate project's docs that's not on the versioned tagged commit marked as pre-release (ie 1.2.2.dev1+1.git.4a5215c

To do this, one would probably need an arbitrary command option defined in the config file.

[florisla]

Posted this incorrectly in the merge request instead of here. Reposting:

I think this feature goes a long way, but will remain too limited for many use cases.

For example, a command might need to take a part value as an argument (e.g. generate_changelog.sh {major}-{minor}-{part}. That would require interpolation, or modifying environment variables.

Other tools specializing in 'running commands' are better suited to do such things. Makefiles come to mind, and I've have had good experiences with invoke (version <1.3.0 due to its issue #660) for example.

Just automate the the release steps (bump, towncrier, git commit, git tag, build, publish, push, ...) there and you're set.

[fizyk]

Thanks for looking at my problem.

Just automate the the release steps

Well... with the help of bumpversion I'm already automating it. The problem is that bump2version allows for committing and tagging, which is super helpful when bumping new version, and it's properly covered in tests. For me that's much better than automating it with bash or make scripts.

Maybe if bumpversion would separate bumping from git operations itself into two commands, or the possibility to get the current version would not require sed to be used, that would've looked like a viable option...

1. bump2version bump [part] no-commit
2. towncrier
3. bump2version commit and tag with version

OR

1. bump2version bump [part] no-commit
2. towncrier
3. bump2version get new version
4. git commit
5. git tag

the first command part could just as well output the version to stdout for grabbing which would make automating it much easier and convenient.

But after thinking about it more, I think you might be right, except you don't. Let me explain. In this scenario, actually in any scenario, towncrier command is no different than git's commands, and they all should be handled externally. Once you have a version generated, you can manually trigger towncrier properly, git commit with proper commit title and generate proper tag. Possibly few other things, like automate notifications about new versions. The only thing you actually need bumpversion for, apart from updating the source code, would be to return the new version for use in all those tasks.

Thank you, and I'll have a bit more to think about now :)

[florisla]

Maybe if bumpversion would separate bumping from git operations itself into two commands, or the possibility to get the current version would not require sed to be used, that would've looked like a viable option...

Easily getting the version is exactly the plan. See #57.

[achary]

I'm in favour of bump2version having the feature as originally proposed.

In general - one could automate ALL the steps bump2version does. I think finding this task inconvenient was what brought the tool to its existence in the first place, wasn't it?

To me the value of this tool comes from the fact it firstly: unifies the flow (so each project using it manages versioning problems the same way, a single command, without reinventing the wheel). Secondly: from that it keeps the following sequence fully transactional:

1. find and modify particular files
2. add changes to the index and make a commit
3. tag it consistently

Breaking this transaction and inventing some extra Makefiles, scripts etc. that eventually cover those steps is of course doable, but: error-prone, potentially leads to duplication of information (templates, tags, messages), and I'll be honest - IMO rather ugly as a final result.

A super nice thing that comes from using bump2version is that when things go wrong, it does not leave you in some intermediate stage between 1. and 2 or 3. and 4. (my experience so far). Achieving same level of comfort with custom split calls in scripts, is a bit harder IMO then it may initially sound.

Yes, really, I'd love to see bump2version being able to execute a custom command in between 1. and 2, so things like changelog generation (or other modification that make sense only for tagged commits) can become part of this transaction.

[florisla]

I see your point.

But I'll add that this goes the other way as well: adding another command will increase the chance that bumpversion fails and creates an invalid state.