Changelogs >


PyUp actively tracks 419,855 Python packages for vulnerabilities to keep your Python environments secure.

Scan your dependencies



* Add ``tbump current-version`` command, to print the current version.
Path by blink1073



* Allow usage of ``python -m tbump`` in addtion to just ``tbump``



* Drop support for Python 3.6
* Drop dependency on ``attr``



* Relax dependency on `cli-ui`
* Use a better example in the README (patch by umonoca)



Add support for other config paths

Added ``-c, --config`` to ``tbump`` command line, allowing using
a different config file than `tbump.toml` (based on early work by

Add support default values for versions fields

Added new ``[[field]]`` option for setting default values for version fields
with no match in the version regex (e.g. prerelease fields),
avoiding errors when these fields are present in a version_template.
Patch by minrk.

For example:

.. code-block:: toml

name = "prerelease"
default = ""


* Relax dependency on `attrs` - we used to have ``attrs <20, >=19``, now we have ``attrs >= 20``.



Instead of pushing twice, which spawns two workflows, ``tbump`` now runs
``git push --atomic <remote> <branch> <tag>``. Patch by InCogNiTo124.



Add support for Python 3.10



Breaking change

If you are using `tbump` with a `pyproject.toml` to bump a project using `poetry`,
you may have found that the `version` key in `[tool.poetry]` was implicitly bumped.

This was considered to be a bug, which means you now have to tell `tbump` about `poetry` explicitly:

.. code-block:: toml

src = "pyproject.toml"
search = 'version = "{current_version}"'

Bug fixes

* Fix 103: Invalid config: Key 'file' error using pyproject.toml,
caused by an update in `tomlkit`
* Fix 93: Do not patch version in `[tool.poetry]` implicitly


* Default development branch is now called `main`.
* Make all `tbump` imports consistent
* Fix compatibly with Python 3.10



* Move out of the TankerHQ organization
* Fix bug in ``tbump init --pyproject``
* Allow usage of newer ``tomlkit`` versions



* Add a ``--no-tag-push`` option to create the tag but not push it



More flexible workflow

* Add a ``--no-push`` option to create the commit and the tag, but not push them
* Add a ``--no-tag`` option to skip creating the tag

Note that if you want to create a commit and run the hooks but nothing else, you
must use ``tbump --no-tag --no-push <new version>``.

If you only want to patch the files use ``tbump --only-patch``.

See `65 <>`_ for more details

pyproject.toml support

Idea and initial implementation by pmav99

* If no ``tbump.toml`` file is present, but a ``pyproject.toml`` file
containing a ``tool.tbump`` section exists, read the configuration from

* ``tbump init``: add a ``--pyproject`` option to append configuration into
an existing ``pyproject.toml`` instead of generating the ``tbump.toml`` file

Bug fixes

* Fix invalid syntax in generated config file (`80 <>`_). Patch by `snadorp`.



* Drop dependency on ``Path Pie``
* Drop support for Python 3.5, add support for Python 3.9



* Mark this project as typed



* If ``github_url`` is found in the config file, display
a link suggesting to create a release on GitHub after
the tag is pushed



* Relax constraint on `path` version



* Switch to `poetry <>`_ for dependencies management and packaging.



* Fix incorrect `python_requires` metadata
* Fix incorrect `entry_points` metadata



* Fix `44`: when running `tbump init`, do not fail if no files are found matching the current version.



* Implement `36 <>`_: The ``--only-patch`` flag now allows skipping any git operations or hook commands.



* Fix `41 <>`_: When run with ``--dry-run``, don't abort if git state is incorrect, just print the error message at the end.



* **Breaking change**: Search strings are now regular expressions
* **Breaking change**: Allow globs in paths (breaking if paths contained ``*``, ``?``, ``[`` or ``]`` characters).


* Preserve line endings when patching files.



* Use new and shiny `cli-ui <>`_ package instead of old `python-cli-ui`



* Rename ``before_push`` section to ``before_commit``: it better reflects at which
moment the hook runs. Note that you can still use ``before_push`` or even ``hook`` if
you want.



* Expose ``tbump.bump_files()`` convenience function.



* **Breaking change**: tbump can now run hooks *after* the push is made. Thus
``[[hook]]`` sections should be renamed to ``[before_push]]`` or

.. code-block:: ini

Before (< 5.0.0), running before commit by default:
name = "some hook"
cmd = "some command"

After (>= 5.00), more explicit syntax:
name = "some hook"
cmd = "some command"

New feature: running after push is made:
name = "some other hook"
cmd = "some other command"

* ``tbump init`` now takes the current version directly on the command line instead of interactively asking for it



* Re-add ``--dry-run``
* Add ``tbump init`` to interactively create the ``tbump.toml`` configuration file



* Bug fix: make sure to push the tag *after* the branch. See `20 <>`_ for the details.



* New feature: you can now specify commands to be run after files have been patched and right before git commands are executed.

.. code-block:: ini

name = "Update Cargo.lock"
cmd = "cargo check"



* Dry run behavior is now activated by default. We start by computing all the changes and then ask if they look good before doing anything. This also means we no
longer need to pause right before calling ``git push``. Consequently, the ``--dry-run`` option is gone.

* Fix inconsistency: 'current version' was sometimes called 'old version'.



* Fix printing a big ugly stacktrace when looking for the old version number failed for one or more files.



* Use annotated tags instead of lightweight tags. Patch by tux3. See `PR 7 <>`_ for the rationale.
* When the current branch does not track anything, ask if we should proceed with file replacements and automatic commit and tag (but do not push) instead of aborting immediately.



* First stable release.

Since we use `semver <>`_ this means tbump is now considered stable.




* Fix regression when using the same file twice



* Allow replacing different types of version. For instance, you may want to write ``pub_version="1.42"`` in one file and ``full_version="1.2.42-rc1"`` in an other.
* Add ``--dry-run`` command line argument
* Improve error handling
* Validate git commit message template
* Validate that current version matches expected regex
* Make sure new version matches the expected regex
* Make sure that custom version templates only contain known groups
* Avoid leaving the repo in an inconsistent state if no match is found