<p>If you follow <a href="https://semver.org/" rel="nofollow noreferrer">Semantic Versioning</a> you could achieve this as a step in the pipeline using <a href="https://libraries.io/pypi/python-semantic-release" rel="nofollow noreferrer">Semantic Release</a>.</p>
<p>This and the <a href="https://semantic-release.gitbook.io/semantic-release/" rel="nofollow noreferrer">original tool it's based on</a> are designed for automated releases as part of a continuous integration and delivery pipeline. From <a href="https://python-semantic-release.readthedocs.io/en/latest/automatic-releases/index.html" rel="nofollow noreferrer">the docs</a>:</p>
<blockquote>
<p>The key point with using this package is to automate your releases and stop worrying about version numbers. Different approaches to automatic releases and publishing with the help of this package can be found below. Using a CI is the recommended approach.</p>
</blockquote>
<p>In your case the workflow would be to do all the testing in pull request, and then when they are merged, a step in the <code>develop</code> branch would run <code>semantic-release publish</code>. Again, referencing the docs, this does the following actions:</p>
<blockquote>
<p>Publish will do a sequence of things:</p>
<ul>
<li>Run semantic-release version.</li>
<li>Push changes to git.</li>
<li>Run build_command and upload the created files to PyPI.</li>
<li>Run semantic-release changelog and post to your vcs provider.</li>
<li>Attach the files created by build_command to GitHub releases.</li>
</ul>
</blockquote>
<p>Part of the benefit of having this included in the pipeline is maintaining a clear and consistent changelog, with the help of a commit message linter like <a href="https://github.com/commitizen-tools/commitizen" rel="nofollow noreferrer">committizen</a>.</p>

CC BY-SA 4.0
2020-08-28T03:05:25.903Z
Thank you. I'll give this a spin and respond when I see how suitable it is.
Robert Rapplean
CC BY-SA 4.0
2020-08-26T20:19:02.317Z
2020-08-26T20:19:02.317Z
Bruce Becker
<p>An independent Jenkins server monitors my develop branch in Team Foundation Server's Git repository and builds a new package when it's updated. The problem I'm having is that it uses the same version, specified in setup.py. I could configure pypi-server to allow overwrites, but prefer to maintain build history.</p>
<p>Theoretically, there could be a build step that checks the version and increments it, but I'm hoping that someone has already done this work and published it somewhere.</p>
<p>Has anyone seen something like this?</p>

CC BY-SA 4.0
2020-08-26T20:20:35.903Z
could you please clarify if your code is hosted on gitlab, github, bitbucket or something else? This may help to narrow the relevant answers.
Bruce Becker
<jenkins><jenkins-pipeline><continuous-deployment><release-management>
How do I use Jenkins to maintain versioning on a Python project?
Robert Rapplean
# How do I use Jenkins to maintain versioning on a Python project?

(Asked by: username_0 on 2020-08-26)

An independent Jenkins server monitors my develop branch in Team Foundation Server's Git repository and builds a new package when it's updated. The problem I'm having is that it uses the same version, specified in setup.py. I could configure pypi-server to allow overwrites, but prefer to maintain build history.

Theoretically, there could be a build step that checks the version and increments it, but I'm hoping that someone has already done this work and published it somewhere.

Has anyone seen something like this?

**Tags:** jenkins, jenkins-pipeline, continuous-deployment, release-management

> **Comments:**
> **username_1**: could you please clarify if your code is hosted on gitlab, github, bitbucket or something else? This may help to narrow the relevant answers.  

---

## 1 answers

### Answer by username_1 on 2020-08-26. Score: 2

If you follow [Semantic Versioning](https://semver.org/) you could achieve this as a step in the pipeline using [Semantic Release](https://libraries.io/pypi/python-semantic-release).

This and the [original tool it's based on](https://semantic-release.gitbook.io/semantic-release/) are designed for automated releases as part of a continuous integration and delivery pipeline. From [the docs](https://python-semantic-release.readthedocs.io/en/latest/automatic-releases/index.html):

> The key point with using this package is to automate your releases and stop worrying about version numbers. Different approaches to automatic releases and publishing with the help of this package can be found below. Using a CI is the recommended approach.

In your case the workflow would be to do all the testing in pull request, and then when they are merged, a step in the `develop` branch would run `semantic-release publish`. Again, referencing the docs, this does the following actions:

> Publish will do a sequence of things:
>
> * Run semantic-release version.
> * Push changes to git.
> * Run build\_command and upload the created files to PyPI.
> * Run semantic-release changelog and post to your vcs provider.
> * Attach the files created by build\_command to GitHub releases.

Part of the benefit of having this included in the pipeline is maintaining a clear and consistent changelog, with the help of a commit message linter like [committizen](https://github.com/commitizen-tools/commitizen).

> **Comments:**
> **username_0**: Thank you. I'll give this a spin and respond when I see how suitable it is.  

---

