How to avoid keeping version number in source code?

Question

Up to now we keep the version number of our python source code in setup.py.

This version gets increased after every successful ci run.

This means the version of central libraries get increased several times per day.

Since the version number is stored in a file in the git repo, every increase of the version number is a new commit.

This means roughly 50% of all commits are not made by humans, but by CI.

I have got the feeling, that we are on the wrong track. Maybe it is no good solution to keep the version number in ci.

How could we avoid the "useless" CI commits which just increase the version number?

How to avoid keeping version number in source code?

Update

We live without manual release since several years. We do not have a versioning scheme like MAJOR.MINOR. And we have not missed this in the past. I know that this does not work for all environments. But it works for my current environment.

We have a version number which looks like this: YEAR.MONTH.X

This means every commit which passes CI is a new release.

After reading the answers I realize: I need to asks myself: Do I have a version number at all? I think no. I have a build number. More is not needed in this context.

(thank you for the up-votes. Before asking this question I was sure that this question will get closed because people will think it is "unclear" or "too broad")

Answer 1

It is a common practice to keep a version number in the source code, there is nothing wrong in that.

You need to separate CI procedures to regular builds, release publishing and release deployment.

Regular builds: run daily or even after each commit, can include static code analysis and automatic tests, check if the code can be built at all. Regular builds should not change the version number.

Release publishing: can only be triggered by explicit manual action by release manager.
The trigger action could be tagging a commit with a new version number, new merge into the release branch, or just a commit that changes version number kept in a special file (e.g. pom.xml). Refer to git flow for example.
Release publishing assigns a new version number (either automatically or manually), commits it into the source code if necessary, builds a binary package with a new version and uploads it to the binary package repository (e.g. Nexus, devpi, local APT repository, Docker registry and so on).

Release deployment: another manually triggered action that takes a ready binary package from a package repository and installs it to the target environment (dev, QA / UAT / staging, part of production for canary deployments or to the whole production environment).

Answer 2

Premises:

I assume these are the premises under which the solution is discussed.

1. Currently version number is kept in a git-tracked source file, but you are OK to get rid of it.
2. No one manually manages version number, nor triggers a release procedure, which includes: (a) increase version number, (b) build from source and (c) store the built result somewhere. These are taken cared by CI, and SHOULD remain that way.

Solution:

1. Instead of writing to a source file and create new commit, CI simply tag the specific commit that passed CI check, then push the tag to remote repo.
2. The build script should read the tag of current HEAD commit, and use it as the version number for publishing a release.
3. Optionally, you might want to use git filter-branch to rewrite your existing git repo history, tag previous release commits for consistency, remove and stop tracking the version number source cile, then get rid of those CI commits.