[rush] rush version command doesn't allow customizing changelog messages

[benkeen]

Hey folks.

The rush version command generates CHANGELOG.md and .json files. Why doesn't it permit providing a message for the changelog? Is there a suggested workaround to customize the message in those files?
https://rushjs.io/pages/commands/rush_version/

[iclanton]

The messages that end up in those files are generated when a project is changed and the developer runs rush change. rush change generates files in common/changes/<project name>/ and then rush version consumes those files and uses them to update the CHANGELOG files.

[benkeen]

Thanks @iclanton. rush change has a very different flow than what we need. In our scenario, teams cut a release on-demand whenever they want - e.g. once a week, once a month, say. The developer would check out master, create a blank branch, bump the package version, push + merge. The new packages are published via a pipeline, again ran on-demand. Everything in those packages are just an accumulation of changes made to any referenced package in our monorepo since the last release.

For this, rush version fit our requirements perfectly. We didn't have to change our flow. The only problem is not being able to control the changelog messages.

I initially investigated rush change, but found it was a poor fit for us, process-wise:

1. we didn't want developers to have to run rush change on all PRs (or even some). It's just one more step devs would have to do,
2. rush change requires a commit back onto the target branch (master/main) which deletes the common/changes files and updates package versions. For security reasons, we're forbidden to automate merging onto our master branch, so this would necessitate human involvement. We didn't want to slow down the process or make it more cumbersome.

btw, the reason I really wanted to use rush publish is that it allows us to delete all our custom pipelines that publish a specific package, targeting it specifically with npm publish. Now we can just have a single pipeline to publish everything, which is working really nicely. Less to maintain.