[FEATURE] : create hotfix on previous version

[alxreed]

Is your feature request related to a problem? Please describe.

With the current version of cocogitto it's not possible to make a hotfix on a previous version. For example, if my acceptance environnement is on 6.8 version and my preproduction / production versions are on 6.7 i can't make a 6.7.1 version only 6.8.1.
It is really frustrating to have to make those fixes by hand when you have a production issue and you need to be as fast as you can.

Describe the solution you'd like
It would be super nice to be able to hotfix previous version(s)

[oknozor]

This is now easier to implement since tag are now sorted in SemVer order instead of date.

Use case

The git log below show a fix commit living on a branch between 1.0.0 and 1.1.0.

* 08c2f5d (HEAD -> master, tag: v1.1.0) chore(version): v1.1.0
* a6ddf88 feat: some feature
* 9bef8f2 (hotfix-branch) fix: fix some prod bug // unreleased hotfix
| * b07f3ed (HEAD -> master, tag: v1.0.0) chore(version): v1.0.0
|/

We should be able to produce a hotfix tag doing the following:

1. git checkout hotfix-branch
2. cog bump --auto | cog bump --patch etc

Implementation notes

• cocogitto should get latest tag starting from current worktree HEAD instead of trying to get all tags.
• Version number should be generated with normal tag validation (i.e: {{version}} > v1.0.0).
• Additional tag validation : {{version}} < next_tag_starting_from(v1.0.0) (do not assume next tag = latest tag)
• Should support auto bump and manual bump failing with safety checks.
• Must not be the default behavior and should be enabled via a dedicated flag (--from-worktree, --unsafe, --force maybe ? )
• Generated changelog should convey the idea that generated tag is not the latest one. Probably using someting like "Patched version" in the changelog heading.
• We need to check that this is not breaking tag to tag git traversal ( patched tag version commits won't be reachable from the later tags). In the example above 9bef8f2 is not reachable from 08c2f5d

[lukehsiao]

As another reference, semantic-release is a popular way to manage releases from conventional commits, and their workflow is described here:

https://semantic-release.gitbook.io/semantic-release/recipes/release-workflow/maintenance-releases