Do you support prerelease suffix such as alpha, beta

[zoonderkins]

We will use alpha, beta on different branch

• 0.0.1-alpha.0 on dev branch
• 0.0.1-beta.0 on test branch
• 0.0.1 on master branch

How to achieve this? Also in CHANGELOG.md will print out something like this:

## [0.0.1-beta.0] - 2021-01-20
xxxxx

## [0.0.1-alpha.0] - 2021-01-19
xxxxx

Thanks

[adamtabrams]

@ookangzheng This test shows the current behavior with suffixes like -alpha.

Are you planning on maintaining 3 separate versions of CHANGELOG.md? One for master, another for test, and another for dev. Each showing only the versions for that branch.

Or are you planning on having a single CHANGELOG.md that shows all the versions for master, test, and dev?

I would normally expect the versions in CHANGELOG.md to mainly reflect the versions for master branch. But maybe I'm not thinking about a certain use case?

[zoonderkins]

We do have some project which maintenance 3 separate versions of CHANGELOG.md and other project have single CHANGELOG.md across 2 different branches (dev --> master).

[adamtabrams]

@ookangzheng I've modified how suffixes are handled in the dev branch of this repo. You can see how it behaves in this test or you can try it out yourself. Would this work for your use case?

[zoonderkins]

I tested out on dev branch gonna update file UNRELEASE.md. If I did a fix and bump version with command change it gave me this error.

Error code:

❯ change
fatal: ambiguous argument '1.0.1-alpha.0..1.0.1': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
added 1.0.1 to UNRELEASE.md

I expect 1.0.1-alpha.0 bump to version 1.0.1-alpha.1

[adamtabrams]

I expect 1.0.1-alpha.0 bump to version 1.0.1-alpha.1

@ookangzheng The SemVer spec doesn't explain exactly how suffixes should be used. This allows developers to implement them in a way that best fits their use case. But it means that change cannot know how a specific project is using suffixes. I've seen suffixes that don't have numbers, others using part of the git commit hash, some that include the date, etc.

So change will default to following the SemVer spec, but it will allow users to manually tag a version if they want a more complicated suffix. In the example that you made 1.0.1-alpha.0 gets a fix commit. That means the patch number MUST be incremented. The next expected version would be 1.0.2 or if you want to manually add a more complex suffix, it could be 1.0.2-alpha.1 or use some other suffix. But if next version doesn't start with 1.0.2 after a fix commit, SemVer isn't being followed.

[zoonderkins]

Thanks for your help 👍

I ended up by using a separate tool such as fsaintjacques/semver-tool and part of logic as reference to generate change log manually.

1. Bump with current prefix
2. git tag -a -m
3. Passing previous tag and current tag or HEAD to generate Change log