[feature] add CalVer support

[Lee-W]

[woile]

This is a tough one, I've read the document https://calver.org/ and it's still not clear how to do it.

It also point out:

it's important to recognize the practicality of each and design the scheme to fit the project

which makes it hard to extract a convention, if it's gonna be tailored to each team.

But it would be a fun experiment to see if commitizen can be flexible enough to support different versioning schemas.

[Lee-W]

This is actually one of the feature requests from Remote Python Pizza attendee 😆 This could be the next one we can play with after changelog.

[gadse]

I think that was my feature request 👋 . I was just checking whether I actually created it here or not, and it seems @Lee-W was faster than me.

I hope I can get to know the codebase fast enough to help implement the feature. 😊

[KyleKing]

I was thinking about this and there might be a straightforward way to handle all of the edge cases for how someone might want to format CalVer using only strftime

commitizen/commitizen/bump.py

Lines 235 to 238 in ba94e3f

	t = Template(tag_format)
	return t.safe_substitute(
	version=version, major=major, minor=minor, patch=patch, prerelease=prerelease
	)

Could be:

t = Template(tag_format)
t_ver = t.safe_substitute(
    version=version, major=major, minor=minor, patch=patch, prerelease=prerelease
)
return datetime.utcnow().strftime(t_ver)

As an example tag_format='%y.%M.%d.$major.$minor-$prerelease' > 21.26.24.1.2a0 (Note: would likely be used in tandem with custom bump rules so that all changes would increment minor rather than patch)

---

Other schemes from projects on https://calver.org/

Project	tag_format	Notes
pip	%y.%major.%minor	21.1.2
PyCharm	%Y.%m.%d	2020.3.5 (but they also have a regular SemVer build, I think)
certifi	%Y.%M.%D	2020.12.5
packaging	%Y.(build)	20.9 / 21.0

See more example formats in the BumpVer README

If that sounds OK, I can submit a PR? Or feel free to handle it because it would be such a small change

(Update 03Sep2021: added more example formats)

[woile]

Sounds interesting! More than welcome to submit a PR! Thanks!

[KyleKing]

Just following up. I implemented the changes, added tests, and updated the documentation in PR #385 that could be ready to merge. There were some CI failures unrelated to the CalVer changes for type errors in toml_config.py

[KyleKing]

See discussion in PR: #385 (comment)

From my experimentation, I feel that mixing CalVer and SemVer should be avoided, but If needed, bumpver is a good alternative, which could be used alongside commitizen

Update: I can't actually close this ticket...oops

[KyleKing]

I've been thinking about this for so long, I thought I created this issue 🤦‍♂️

Feel free to ignore my thoughts and implement CalVer anyway! Sorry @Lee-W

[Lee-W]

Not at all. Thanks for your hard work 🙂 It was just a random idea to see whether it's possible to support CalVer. It's super helpful to know it might not be a good idea. I'm thinking of adding "why we don't implement CalVer" to FAQ. @KyleKing Not sure whether you're interested in adding this section. I can do it when I have time as well 🙂

[KyleKing]

Sure, I would be happy to open a PR!

I searched for someone more credible discussing why not to combine the two, but I really couldn't find anything. Most articles presented the decision as "SemVer OR CalVer" so I think I can work that into a good explanation