16

TLDR;

The question is as the title says.

To bump or not to bump?

I started using bump2version and then discovered setuptools_scm (fairly new to developing full-fledged python programs) and now I am confused.

https://setuptools.readthedocs.io/en/latest/history.html#v20-6-0 (ancient, I know, and I use v40-x-x) mentions the integration of bumpversion, however, there is no mention of ever dropping bumpversion support in subsequent changelogs.

Meanwhile, 1.4 Extending and Reusing Setuptools section of setuptools documentation mentions setuptools_scm (and setuptools_svn) for integration with git, Hg and svn.

BLAB (Bottom-Line-At-Bottom)

So, the question is: Is bumpversion deprecated/obsolete?

Addendum

To further clarify I will try and explain my use-case a bit more

I have a super-project that has multiple subprojects.

super
├───base/
├───core/
├───lib/
├───version/requirements.txt
└───modules/
    ├───module-1/
    ├───module-2/
    ├───module-3/
    ├───module-4/
    └───module-5/

The super is a master git, with each subproject as a submodule (which have their own submodules) and of course, each of them maintains its own release versions (which is easy enough)

A release of the project is comprised of signed-off modules that are inter-compatible with everything else.

My current approach

I am currently using a submodule called version that maintains a requirements.txt + pyproject.toml and pulls the whole thing together into a distributable package. Following guidelines in https://github.com/pypa/pipfile/issues/27 and somewhat pulling from https://caremad.io/posts/2013/07/setup-vs-requirement/

The question remains: Is there a canonical approach to doing something like this?

gerrit
  • 24,025
  • 17
  • 97
  • 170
Ahmed Masud
  • 21,655
  • 3
  • 33
  • 58
  • 2
    It depends on where you keep the Single Source of Truth for the version. If it's the setup script and updating the version string in it is the propagation event (e.g. script commit with changed version var creates new VCS tags), then you can use `bumpversion`; if it's the latest VCS tag and tagging is a propagation event (e.g. tag creation triggers new build with updated version var in setup script), then use `setuptools-scm`. Both are viable approaches. – hoefling Jul 07 '19 at 20:15
  • My case is the latter so setuptools_scm seems to be the way to go :^) – Ahmed Masud Jul 07 '19 at 20:24
  • Hi @AhmedMasud, you still need information about bumpversion vs setuptools-scm? Or only on your remaining question about a "canonical way" to perform your versions' management need? – Bsquare ℬℬ Jul 27 '19 at 11:05
  • @Bsquareℬℬ any and all information welcome! If you are looking to add wisdom from experience, i'll consider that a good answer :-) – Ahmed Masud Jul 28 '19 at 21:10

1 Answers1

4

If you use setuptools_scm, you probably don't need bump2version. And vice versa.

There is no 'canonical' way to bump a version in Python. Multiple tools exist, and you can use the one you like (or none at all).

The message in the setuptools changelog is about what the setuptools authors use in their own Git repository. They still use bump2version, as seen in this config file.

The projects setuptools_scm and setuptools are similar in name but they're totally independent.

florisla
  • 12,668
  • 6
  • 40
  • 47