Read and process Commands - closes #100

[fizyk]

I suppose ther few things to adjust and fix, for now the basic assumptions are working for me, will adjuist the changeset as well as see the tests later

[ekohl]

Could you describe a bit more what this PR is intended to resolve? It'll be particularly interesting to see when this is ran. I was wondering whether this was pre or post but looking at #100 this looks like it's actually in the middle. Is that correct?

[fizyk]

@ekohl That's correct. My use case is to actually use combination of two tools bump(2)version and towncrier.

I am aiming for the following flow:

1. Bump version across project
2. Trigger towncrier to generate changelog out of the fragments with title and correct version.
3. Commit all changes as a release commit (tagged)

This way I'll have

• changelog rst document generated with exact version and on exact commit/tag, not before or after.

• correct underline in the changelog entry title

• version's documentation will also contain exact changelog for the release

• pre - could be problematic due to the fact that I'd have to manually calculate the next version, while otherwise the bumpversion can do it for me

• post - also could be problematic when I generate documentation on tagged commit and push it on the server with exact version, and running towncrier post would mean I'll have documentation with sstale changelog (up to previous version)

[florisla]

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.

[florisla]

This requires a decision on whether this is desired (#100).

If approved, this merge request will need documentation and unit tests before it can be merged.

[c4urself]

@fizyk -- thanks for the time you spent on this and helping us think through this. Unfortunately, unless @ekohl and @florisla strongly disagree I think adding subcommands to bump2version would make it much too bloated. Basically, we're taking the fact that bump2version knows how to git-tag and then extending that fact to make it do something before git-tag happens. That begs the question: why not git-tag yourself? IMHO we should stick to "do one thing and do it well" and not add more stuff that's hard to maintain. @florisla's suggestion above is how I would go about doing this. Happy to discuss further...