Versioning of the projects

[foarsitter]

Description

bump2version: manage your version variables.

By running bump2version patch it increases the current_version variable in setup.cfg. The line [bumpversion:file:config/settings/base.py] in setup.cfg tells the tool to replace the previous version number with the current version in config/settings/base.py

setup.cfg

[bumpversion]
current_version = 0.3.6
[bumpversion:file:config/settings/base.py]

Rationale

A struggle of my is to keep the version number consistent and keep track of the different places where I need to reference to the version number.

This project adds a __version__ variable to {{cookiecutter.project_slug}}/__init__.py but we need the version number elsewhere too (i.e: in our pipeline).

How do you manage this problem? Is bump2version the way to go?

[browniebroke]

I think this is a subjective topic and not one that is very clear in the context of an application that is continually deployed. When do you bump the major/minor/patch version? Who cares about this version? Users visiting my site won't usually see the version anywhere...

What we do at work is create a tag based on the date, which looks like this v20211202.1. We bump the final digit each time a PR is merged, and it goes back to 1 every day. Looks like bump2version can be configured to support it, but it doesn't seem like the main use case.

For a library, it's obviously different, and on some projects which are distributed to PyPI, I use python-semantic-release which provides an all-in-one solution: first updating changelog & version, then tagging and finally releasing.

I don't think the consensus is clear enough to make it part of the template, but I guess it's worth keeping as discussion.