fix(#271): add annotated_tag option to bump

[diefans]

Enable creation of annotated tags when bumping.

Description

Create annotated tags, when bumping.

Checklist

• Add test cases to all the changes you introduce
• Run ./script/format and ./script/test locally to ensure this change passes linter check and test
• Test the changes on the local machine manually
• Update the documentation for the changes

Expected behavior

With annotated_tag enabled commitizen will create annotated tag instead of lightweight ones.

Steps to Test This Pull Request

Use cz bump --annotated_tag or annotated_tag = 1 in config file

Additional context

maybe related to #261 ???

[codecov]

Codecov Report

Merging #272 into master will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@ Coverage Diff @@## master #272 +/- ##
==========================================
+ Coverage 96.61% 96.62% +0.01% 
==========================================
Files 33 33 Lines 915 919 +4 ==========================================
+ Hits 884 888 +4 
Misses 31 31 

Flag	Coverage Δ
#unittests	96.62% <100.00%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
commitizen/cli.py	97.36% <ø> (ø)
commitizen/__version__.py	100.00% <100.00%> (ø)
commitizen/commands/bump.py	90.58% <100.00%> (ø)
commitizen/commands/check.py	100.00% <100.00%> (ø)
commitizen/git.py	95.55% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d8e9bad...d2b0ebe. Read the comment docs.

[woile]

Even if this were unrelated to the original issue (not triggering a workflow). I think it would be useful for traceability. An annotated tag adds:

• date
• creator
• message -> it could even contain the changes from the release which would appear in the changelog

I'll test how it could works, for v3 could be the default.

What do you think @Lee-W ?

[Lee-W]

for consistency, I'll suggest using --annotated_tag

[Lee-W]

If my understand is correct, we can use cz bump -at and set it in config to achive it. If so, I'd suggest adding both usages here.

[Lee-W]

Maybe we can change the help message to create an annotated tag (by default, commitizen creates lightweight tag)

[Lee-W]

to enhance readbility, I would suggest make self.bump_settings.get("annotated_tag", False) or or bool(self.config.settings.get("annotated_tag", False)) a variable. I read this line for a few times to understand

[Lee-W]

Even if this were unrelated to the original issue (not triggering a workflow). I think it would be useful for traceability. An annotated tag adds:

* date
* creator
* message -> it could even contain the changes from the release which would appear in the changelog

I'll test how it could works, for v3 could be the default.

What do you think @Lee-W ?

Although I love this feature, I'm a bit against making it a default option. I'm not sure how common annotated tag is used in practice.

[woile]

Doing man git-tag gives this:

Annotated tags are meant for release while lightweight tags are meant for private or temporary object labels.

Here's an answer from SO

I have the same concerns as you, not sure how used is in practice, spite of what the documentation says.
But let's see, maybe once we start using it, it does make more sense.

[Lee-W]

Got it. It makes more sense after reading it. I'm now neutral to make it as a default.

[woile]

Please remove the changes on CHANGELOG.md and rebase. Looks good.

[woile]

This was already added