Step 4 might be confusing. The logic makes sense. But we might need to design it in another way. Adding a --force-increase flag might make more sense? @woile @noirbizarre Would love to see what you think 🙂

I'm not a big fan of this change, because things start getting confusing. I'd rather raise an error of the wrong value is used. But, I also struggle to see if it's worth to enforce it. Maybe behind a setting "enforce_prereleases"

What's the motivation for this PR?

What's the motivation for this PR?

This PR builds on top of PR #799, and came from our branching model at work: PR branches merge into "downstream" branches and release packages on each branch. So,

• the development branch (publishes pre-release alpha) merges into
• the testing branch (publishes pre-release beta) which merges into
• the staging branch (publishes pre-release rc) which merges into
• the main branch (publishes the final release).

Each of these downstream merges automatically creates a bump commit on the target branch and a tag on the bump commit. However, to ensure a consistent history across branches, upstream branches always automatically rebase on top of downstream branches. I illustrated @eduardocardoso’s example above:

cz-800

On the right side of the image you have the growing git log history where you can see the bump: commits; that history is the same on all branches.

Because we continuously rebase downstream branches, we quickly get into a place where the development branch has a bump: 0.1.1rc0 commit (including tag) — the next commit to development must bump that rc0 to preserve linearity: it can not bump below rc0. Does that make sense?

I see 🤔 I'm fine with it as long as proper documentation is added, I can already foresee users complaining that doing cz bump --prerelease alpha → bumps to 0.1.1b1 raises the wrong prerelease, and I won't know why 😆

I think we are taking an opinionated approach on how it should be done, and that's what I would like to see reflected in the docs. I'm not a big user of prereleases myself, so I trust you on this model.

Agreed — and it probably makes sense to add a command-line switch that enables precedence bumping. For example if the current version is 0.1.1b0 then

• cz bump --prerelease beta bumps to 0.1.1b1
• cz bump --prerelease alpha is an error because a beta tag was expected
• cz bump --prerelease (no argument!) bumps to to 0.1.1b1 or
• cz bump --prerelease alpha --consider-precedence also bumps to 0.1.1b1

We can either make the argument to --prerelease optional in which case it detects and bumps based on the tag with the highest precedence, or we add an argument that explicitly enables bumping based on the tag with the highest precedence. (See also our previous discussions in issues #688 and conventional-commits/conventionalcommits.org#398.)

Also note that this PR addresses the uncertainty of this test:

Instead of expecting "graceful" handling of this case, we can now clearly define the expected behavior.