Add a CLI argument that allows to specify a prerelease prefix

[arazabishov]

SemVer specification allows prerelease version to be a string/number combination. For example: 1.0.0-beta.5, where beta.5 is a prerelease version. Unfortunately, beachball does not give a user control over the prerelease prefix. This PR addresses this at the level of the bump command.

This is extremely useful if you want to scope versions to avoid conflicts. For example, 1.0.0-beta.2 and 1.0.0-alpha.2 are two different versions. Without --prerelease-prefix option, beachball will be calculating the same version (1.0.0-2 and 1.0.0-2) for two packages that have different contents.

[christiango]

Is there somewhere we also need to update to make sure this new option shows up in the docs/website?

[christiango]

Are there scenarios where we wouldn't want the entire repo to be limited to the same prerelease prefix? Say some might want beta while others are on alpha, or hotfix or something. Wondering if CLI is the right place to expose this vs in the change file or in the beachball configuration

[arazabishov]

Is there somewhere we also need to update to make sure this new option shows up in the docs/website?

Done! I've updated the help command and added the flag description to the options page.

Are there scenarios where we wouldn't want the entire repo to be limited to the same prerelease prefix? Say some might want beta while others are on alpha, or hotfix or something. Wondering if CLI is the right place to expose this vs in the change file or in the beachball configuration

I agree! In general, users should have granular control over the prerelease prefix, ideally per package. It will require changing the prompt flow of the change command and a new field for change files. The CLI arg, however, can be used as an additional mechanism for overriding prefix for all packages (this is very handy on CIs, for example). Unfortunately, I had time only to implement the latter. As alternative, I can create a task for building the entire flow using change files and assign myself to it.

[christiango]

Is there somewhere we also need to update to make sure this new option shows up in the docs/website?

Done! I've updated the help command and added the flag description to the options page.

Are there scenarios where we wouldn't want the entire repo to be limited to the same prerelease prefix? Say some might want beta while others are on alpha, or hotfix or something. Wondering if CLI is the right place to expose this vs in the change file or in the beachball configuration

I agree! In general, users should have granular control over the prerelease prefix, ideally per package. It will require changing the prompt flow of the change command and a new field for change files. The CLI arg, however, can be used as an additional mechanism for overriding prefix for all packages (this is very handy on CIs, for example). Unfortunately, I had time only to implement the latter. As alternative, I can create a task for building the entire flow using change files and assign myself to it.

As long as we think this doesn't make it any harder to support per package overrides when folks ask for it, it sounds reasonable to go with this approach to start.