<div align="center">
<p align="center">
<img alt="logo" src="https://raw.githubusercontent.com/mbarkhau/bumpver/master/bumpver_128.png">
</p>
</div>
# [BumpVer: Automatic Versioning][url_repo]
With the CLI command `bumpver`, you can search for and update version strings in your project files. It has a flexible pattern syntax to support many version schemes ([SemVer][url_semver_org], [CalVer][url_calver_org] or otherwise). BumpVer features:
- Configurable version patterns
- Optional Git or Mercurial integration
- Works with plaintext, so you can use it with any project.
[url_repo]: https://github.com/mbarkhau/bumpver
[url_semver_org]: https://semver.org/
[url_calver_org]: https://calver.org/
Project/Repo:
[![MIT License][img_license]][url_license]
[![Supported Python Versions][img_pyversions]][url_pyversions]
[![CalVer 2024.1130][img_version]][url_version]
[![PyPI Releases][img_pypi]][url_pypi]
[![PyPI Downloads][img_downloads]][url_downloads]
Code Quality/CI:
[![GitHub Build Status][img_github_build]][url_github_build]
[![GitLab Build Status][img_gitlab_build]][url_gitlab_build]
[![Type Checked with mypy][img_mypy]][url_mypy]
[![Code Coverage][img_codecov]][url_codecov]
[![Code Style: sjfmt][img_style]][url_style]
[img_github_build]: https://github.com/mbarkhau/pycalver/workflows/CI/badge.svg
[url_github_build]: https://github.com/mbarkhau/pycalver/actions?query=workflow%3ACI
[img_gitlab_build]: https://gitlab.com/mbarkhau/pycalver/badges/master/pipeline.svg
[url_gitlab_build]: https://gitlab.com/mbarkhau/pycalver/pipelines
[img_codecov]: https://gitlab.com/mbarkhau/pycalver/badges/master/coverage.svg
[url_codecov]: https://mbarkhau.gitlab.io/pycalver/cov
[img_license]: https://img.shields.io/badge/License-MIT-blue.svg
[url_license]: https://github.com/mbarkhau/bumpver/blob/master/LICENSE
[img_mypy]: https://img.shields.io/badge/mypy-checked-green.svg
[url_mypy]: https://mbarkhau.gitlab.io/pycalver/mypycov
[img_style]: https://img.shields.io/badge/code%20style-%20sjfmt-f71.svg
[url_style]: https://gitlab.com/mbarkhau/straitjacket/
[img_downloads]: https://pepy.tech/badge/bumpver/month
[url_downloads]: https://pepy.tech/project/bumpver
[img_version]: https://img.shields.io/static/v1.svg?label=CalVer&message=2024.1130&color=blue
[url_version]: https://pypi.org/project/bumpver/
[img_pypi]: https://img.shields.io/badge/PyPI-wheels-green.svg
[url_pypi]: https://pypi.org/project/bumpver/#files
[img_pyversions]: https://img.shields.io/pypi/pyversions/bumpver.svg
[url_pyversions]: https://pypi.python.org/pypi/bumpver
<!--
$ pip install -U md-toc
$ md_toc --in-place --skip-lines 10 github README.md
-->
<!--TOC-->
- [Overview](#overview)
- [Search and Replace](#search-and-replace)
- [Name Change PyCalVer -> BumpVer](#name-change-pycalver---bumpver)
- [Related Projects/Alternatives](#related-projectsalternatives)
- [Example Usage](#example-usage)
- [Testing a `version_pattern`](#testing-a-version_pattern)
- [Using `MAJOR`/`MINOR`/`PATCH` (SemVer Parts)](#using-majorminorpatch-semver-parts)
- [Auto Increment Parts: `BUILD`/`INC0`/`INC1`](#auto-increment-parts-buildinc0inc1)
- [Persistent Parts: `BUILD`/`TAG`/`PYTAG`](#persistent-parts-buildtagpytag)
- [Searching for Patterns with `grep`](#searching-for-patterns-with-grep)
- [Reference](#reference)
- [Command Line](#command-line)
- [Part Overview](#part-overview)
- [Normalization Caveats](#normalization-caveats)
- [Pattern Examples](#pattern-examples)
- [Week Numbering](#week-numbering)
- [Configuration](#configuration)
- [Configuration Setup](#configuration-setup)
- [Debugging Configuration](#debugging-configuration)
- [Bump It Up](#bump-it-up)
- [Version State](#version-state)
- [The Current Version](#the-current-version)
- [Dry Mode](#dry-mode)
- [VCS Parameters (git/mercurial)](#vcs-parameters-gitmercurial)
<!--TOC-->
## Overview
### Search and Replace
With `bumpver`, you configure a single `version_pattern` which is then used to
1. Search for version strings in your project files
2. Replace these with an updated/bumped version number.
Your configuration might look something like this:
```
# pyproject.toml
[bumpver]
current_version = "1.5.2"
version_pattern = "MAJOR.MINOR.PATCH"
[bumpver.file_patterns]
"setup.py" = [
'version="{version}",$',
]
"src/mymodule/__init__.py" = [
'^__version__ = "{version}"$',
]
```
Using this configuration, the output of `bumpver update --dry` might look something like this:
```diff
$ bumpver update --patch --dry
INFO - Old Version: 1.5.2
INFO - New Version: 1.5.3
--- setup.py
+++ setup.py
@@ -63,7 +63,7 @@
name="mymodule",
- version="1.5.2",
+ version="1.5.3",
description=description,
--- src/mymodule/__init__.py
+++ src/mymodule/__init__.py
@@ -3,3 +3,3 @@
-__version__ = "1.5.2"
+__version__ = "1.5.3"
```
### Name Change PyCalVer -> BumpVer
This project was originally developed under the name PyCalVer, with the intent to support various CalVer schemes. The package has since been renamed from PyCalVer to BumpVer and the CLI command from `pycalver` to `bumpver`.
This name change is to reduce confusion that this project is only suitable for Python projects or only for CalVer versioning schemes, neither of which is the case.
### Related Projects/Alternatives
If you are looking for an alternative, BumpVer was heavily influenced by [bumpversion/bump2version][url_bump2version]. You may also wish to take a look at their list of related projects: [bump2version/RELATED.md][url_bump2version_related]
[url_bump2version]: https://github.com/c4urself/bump2version/
[url_bump2version_related]: https://github.com/c4urself/bump2version/blob/master/RELATED.md
## Example Usage
You can override the date used by `bumpver` with the `--date=<isodate>` option. Adding this every time would be distracting, so the examples assume the following date:
```shell
$ date --iso
2020-10-15
```
### Testing a `version_pattern`
To test a `version_pattern` and how to increment it, you can use `bumpver test`:
```shell
$ bumpver test 'v2020.37' 'vYYYY.WW'
New Version: v2020.41
```
A `version_pattern` consists of three kinds of characters:
- Literal text, such as `v`, `.`, and `-`, typically used as delimiters.
- A [valid part](#parts-overview) such as `YYYY`/`WW` in the previous example.
- Square brackets `[]` to mark an optional segment.
The following example uses all three: `vYYYY.WW[-TAG]`
```
vYYYY.WW[-TAG]
literal text ^ ^ ^
```
```shell
$ bumpver test 'v2020.37-beta' 'vYYYY.WW[-TAG]'
New Version: v2020.41-beta
PEP440 : 2020.41b0
```
Here we see the week number changed from 37 to 41. The test command also shows the normalized version pattern according to [PEP440][pep_440_ref]. This removes the `"v"` prefix and shortens the release tag from `-beta` to `b0`.
[pep_440_ref]: https://www.python.org/dev/peps/pep-0440/
To remove the release tag, use the option `--tag=final`.
```shell
$ bumpver test 'v2020.37-beta' 'vYYYY.WW[-TAG]' --tag=final
New Version: v2020.41
PEP440 : 2020.41
```
### Using `MAJOR`/`MINOR`/`PATCH` (SemVer Parts)
A CalVer `version_pattern` may not require any flags to determine which part should be incremented, so long as the date has changed.
With SemVer you must always specify one of `--major/--minor/--patch`.
```shell
$ bumpver test '1.2.3' 'MAJOR.MINOR.PATCH[PYTAGNUM]' --major
New Version: 2.0.0
$ bumpver test '1.2.3' 'MAJOR.MINOR.PATCH[PYTAGNUM]' --minor
New Version: 1.3.0
$ bumpver test '1.2.3' 'MAJOR.MINOR.PATCH[PYTAGNUM]' --patch
New Version: 1.2.4
$ bumpver test '1.2.3' 'MAJOR.MINOR.PATCH[PYTAGNUM]' --patch --tag=beta
New Version: 1.2.4b0
$ bumpver test '1.2.4b0' 'MAJOR.MINOR.PATCH[PYTAGNUM]' --tag-num
New Version: 1.2.4b1
```
These non date based parts also make sense for a CalVer `version_pattern`, so that you can create multiple releases in the same month. It is common to include e.g. a `PATCH` part.
```shell
$ bumpver test '2020.10.0' 'YYYY.MM.PATCH' --patch
New Version: 2020.10.1
```
Without this flag, we would get an error if the date is still in October.
```shell
$ date --iso
2020-10-15
$ bumpver test '2020.10.0' 'YYYY.MM.PATCH'
ERROR - Invalid arguments or pattern, version did not change.
ERROR - Version did not change: '2020.10.0'. Invalid version and/or pattern 'YYYY.MM.PATCH'.
INFO - Perhaps try: bumpver test --patch
```
Once the date is in November, the `PATCH` part will roll over back to zero. This happens whenever parts to the left change (in this case the year and month), just as it does if `MAJOR` or `MINOR` were incremented in SemVer.
```shell
$ bumpver test '2020.10.1' 'YYYY.MM.PATCH' --date 2020-11-01
New Version: 2020.11.0
```
The rollover to zero will happen even if you use the `--patch` argument, so that your first release in a month will always have a `PATCH` set to 0 instead of 1. You can make the `PATCH` part optional with `[.PATCH]` and always supply the `--patch` flag in your build script. This will cause the part to be omitted when 0 and added when > 0.
```shell
$ bumpver test '2020.9.1' 'YYYY.MM[.PATCH]' --patch
New Version: 2020.10
$ bumpver test '2020.10' 'YYYY.MM[.PATCH]' --patch
New Version: 2020.10.1
$ bumpver test '2020.10.1' 'YYYY.MM[.PATCH]' --patch
New Version: 2020.10.2
```
With CalVer, the version is based on a calendar date, so you only have to specify such flags if you've already published a release for the current date. Without such a flag, BumpVer will show the error, that the "version did not change".
```shell
$ bumpver test 'v2020.41-beta0' 'vYYYY.WW[-TAGNUM]'
ERROR - Invalid arguments or pattern, version did not change.
ERROR - Invalid version 'v2020.41-beta0' and/or pattern 'vYYYY.WW[-TAGNUM]'.
```
In this case you have to change one of the parts that are not based on a calendar date.
```shell
$ bumpver test 'v2020.41-beta0' 'vYYYY.WW[-TAGNUM]' --tag-num
New Version: v2020.41-beta1
PEP440 : 2020.41b1
$ bumpver test 'v2020.41-beta0' 'vYYYY.WW[-TAGNUM]' --tag=final
New Version: v2020.41
PEP440 : 2020.41
```
If a pattern is not applicable to a version string, then you will get an error message.
```shell
$ bumpver test '2020.37' 'YYYY.MM' # expected to fail because 37 is not valid for part MM
ERROR - Incomplete match '2020.3' for version string '2020.37' with pattern 'YYYY.MM'/'(?P<year_y>[1-9][0-9]{3})\.(?P<month>1[0-2]|[1-9])'
ERROR - Invalid version '2020.37' and/or pattern 'YYYY.MM'.
```
This illustrates that each pattern is internally translated to a regular expression which must match the version string. The `--verbose` flag will show a verbose form of the regular expression, which may help to debug the discrepancy between the pattern and the version.
```shell
$ bumpver test 'v2020.37' 'YYYY.WW' --verbose # missing "v" prefix
INFO - Using pattern YYYY.WW
INFO - regex = re.compile(r"""
(?P<year_y>[1-9][0-9]{3})
\.
(?P<week_w>5[0-2]|[1-4][0-9]|[0-9])
""", flags=re.VERBOSE)
ERROR - Invalid version string 'v2020.37' for pattern ...
```
To fix the above, you can either remove the "v" prefix from the version or add it to the pattern.
```shell
$ bumpver test 'v2020.37' 'vYYYY.WW' # added "v" prefix
New Version: v2020.41
PEP440 : 2020.41
```
### Auto Increment Parts: `INC0`/`INC1`/`BUILD`
These parts are incremented automatically, and do not use/require a CLI flag: `BUILD`/`INC0`/`INC1`.
```shell
$ bumpver test '2020.10.1' 'YYYY.MM.INC0'
New Version: 2020.10.2
$ bumpver test '2020.10.2' 'YYYY.MM.INC0' --date 2020-11-01
New Version: 2020.11.0
```
You can make the part optional using the `[PART]` syntax and it will be added/removed as needed.
```shell
$ bumpver test '2020.10' 'YYYY.MM[.INC0]'
New Version: 2020.10.1
$ bumpver test '2020.10.1' 'YYYY.MM[.INC0]' --date 2020-11-01
New Version: 2020.11
```
You can the `BUILD` part to [maintain lexical ordering][url_pypi_lexid] of version numbers. This means that the expression `older < newer` will always be true, whether you are dealing with integers or strings, whether you are using software that understands how to parse version numbers or not.
```shell
$ bumpver test '2020.1001' 'YYYY.BUILD'
New Version: 2020.1002
$ bumpver test '2020.1002' 'YYYY.BUILD'
New Version: 2020.1003
$ bumpver test '2020.1999' 'YYYY.BUILD'
New Version: 2020.22000
```
[url_pypi_lexid]: https://pypi.org/project/lexid/
### Persistent Parts: `BUILD`/`TAG`/`PYTAG`
The `BUILD` and `TAG` parts will not rollover/reset. Instead they are carried forward from one version to the next.
```shell
$ bumpver test 'v2020.1051-beta' 'vYYYY.BUILD[-TAG]'
New Version: v2020.1052-beta
PEP440 : 2020.1052b0
$ bumpver test 'v2020.1051-beta' 'vYYYY.BUILD[-TAG]' --date 2021-01-01
New Version: v2021.1052-beta
PEP440 : 2021.1052b0
$ bumpver test 'v2020.1051-beta' 'vYYYY.BUILD[-TAG]' --tag=rc
New Version: v2020.1052-rc
PEP440 : 2020.1052rc0
```
To remove a release tag, mark it as final with `--tag=final`.
```shell
$ bumpver test 'v2020.1051-beta' 'vYYYY.BUILD[-TAG]' --tag=final
New Version: v2020.1052
PEP440 : 2020.1052
```
### Explicit `--set-version`
If the various automatic version incrementing methods don't work for you, you can explicitly do `--set-version=<version>`.
```diff
$ bumpver update --dry --set-version="v2020.1060"
INFO - Old Version: v2020.1051-beta
INFO - New Version: v2020.1060
--- setup.py
+++ setup.py
@@ -63,7 +63,7 @@
name="mymodule",
- version="2020.1051b0",
+ version="2020.1060",
description=description,
--- src/mymodule/__init__.py
+++ src/mymodule/__init__.py
@@ -3,3 +3,3 @@
-__version__ = "v2020.1051-beta"
+__version__ = "v2020.1060"
```
<!--
#### Add git hash to version string
If you want to build a package straight from your git repository,
without making a release first, you can explictly add git hash to
the version number using ``GITHASH`` version part.
Let's say your ``pyproject.toml`` looks like this:
```ini
[bumpver]
...
version_pattern = "YYYY.BUILD[-TAG][GITHASH]"
...
```
Then, to update all configured files, you need to execute this command:
```shell
$ bumpver update --no-commit --no-tag --set-version="v202202.1085.8+ged2c3aaf"
```
This will modify your source tree, but won't commit or tag
anything, so you can build your packages with that version
number. Then, remember to reset local changes after (by typing
``git reset --hard``) as standard bumpver behaviour with such
version number makes not much sense.
-->
### Searching for Patterns with `grep`
You can use `bumpver grep` to test and debug entries for your configuration.
```shell
$ bumpver grep \
'__version__ = "YYYY.MM[-TAGNUM]"' \
src/module/__init__.py
3:
4: __version__ = "2020.9-beta1"
5:
```
When searching your project files for version strings, there are some limitations to keep in mind:
1. A version string cannot span multiple lines.
2. Brackets `[]` can be escaped with backslash: `\[\]`.
3. There is no way to escape a valid part (so you cannot match the literal text `YYYY`).
Note that everything in the pattern is treated as literal text, except for a valid part (in all caps).
```
__version__ = "YYYY.MM[-TAGNUM]"
literal text ^^^^^^^^^^^^^^^ ^ ^ ^
```
When you write your configuration, you can avoid repeating your version pattern in every search pattern, by using these placeholders
- `{version}`
- `{pep440_version}`
Applied to the above example, you can instead write this:
```shell
$ bumpver grep \
--version-pattern "YYYY.MM[-TAGNUM]" \
'__version__ = "{version}"' \
src/module/__init__.py
3:
4: __version__ = "2020.9-beta1"
5:
```
The corresponding configuration would look like this.
```ini
[bumpver]
current_version = "2020.9-beta1"
version_pattern = "YYYY.MM[-TAGNUM]"
...
[bumpver:file_patterns]
src/module/__init__.py
__version__ = "{version}"
...
```
If you use a version pattern that is not in the PEP440 normalized form (such as the one above), you can nonetheless match version strings in your project files which *are* in the [PEP440 normalized form][url_pep_440]. To do this, you can use the placeholder `{pep440_version}` instead of the `{version}` placeholder.
```shell
$ bumpver grep --version-pattern "YYYY.MM[-TAGNUM]" 'version="{pep440_version}"' setup.py
setup.py
65: url="https://github.com/org/project",
66: version="2020.9b1",
67: description=description,
```
The placeholder `{version}` matches `2020.9-beta1`, while the placeholder `{pep440_version}` matches `2020.9b1` (excluding the "v" prefix, the "-" separator and with a short form release tag "b1" instead of "beta1"). These two placeholders make it possible to mostly use your preferred format for version strings, but use a PEP440 compliant/normalized version string where appropriate.
[url_pep_440]: https://www.python.org/dev/peps/pep-0440/
As a ~~neat trick~~ further illustration of how the search and replace works, you might wish to keep the year of your copyright headers up to date.
```shell
$ bumpver grep 'Copyright (c) 2018-YYYY' src/mymodule/*.py | head
src/mymodule/__init__.py
3:
4: # Copyright (c) 2018-2020 Vandelay Industries - All rights reserved.
5:
src/mymodule/config.py
3:
4: # Copyright (c) 2018-2020 Vandelay Industries - All rights reserved.
5:
```
The corresponding configuration for this pattern would look like this.
```ini
[bumpver:file_patterns]
...
src/mymodule/*.py
Copyright (c) 2018-YYYY Vandelay Industries - All rights reserved.
```
Note that there must be a match for every entry in `file_patterns`. If there is no match, `bumpver` will show an error. This ensures that a pattern is not skipped when your project changes. In this case the side effect is to make sure that every file has a copyright header.
```shell
$ bumpver update --dry
ERROR - No match for pattern 'Copyright (c) 2018-YYYY Vandelay Industries - All rights reserved.'
ERROR -
# https://regex101.com/?flavor=python&flags=gmx®ex=Copyright%5B%20%5D%5C%28c%5C%29%0A%5B%20%5D2018%5C-%0A%28%3FP%3Cyear_y%3E%5B1-9%5D%5B0-9%5D%7B3%7D%29%0A%5B%20%5DVandelay%5B%20%5DIndustries%5B%20%5D%5C-%5B%20%5DAll%5B%20%5Drights%5B%20%5Dreserved%5C.
regex = re.compile(r"""
Copyright[ ]\(c\)
[ ]2018\-
(?P<year_y>[1-9][0-9]{3})
[ ]Vandelay[ ]Industries[ ]\-[ ]All[ ]rights[ ]reserved\.
""", flags=re.VERBOSE)
ERROR - No patterns matched for file 'src/mymodule/utils.py'
```
## Reference
### Command Line
<!-- BEGIN bumpver --help -->
```
$ bumpver --help
Usage: bumpver [OPTIONS] COMMAND [ARGS]...
Automatically update version strings in plaintext files.
Options:
--version Show the version and exit.
-v, --verbose Control log level. -vv for debug level.
-h, --help Show this message and exit.
Commands:
grep Search file(s) for a version pattern.
init Initialize [bumpver] configuration.
show Show current version of your project.
test Increment a version number for demo purposes.
update Update project files with the incremented version string.
```
<!-- END bumpver --help -->
<!-- BEGIN bumpver update --help -->
```
$ bumpver update --help
Usage: bumpver update [OPTIONS]
Update project files with the incremented version string.
Options:
-d, --dry Display diff of changes, don't rewrite
files.
-f, --fetch / -n, --no-fetch Sync tags from remote origin.
-v, --verbose Control log level. -vv for debug level.
--allow-dirty Commit even when working directory is has
uncomitted changes. (WARNING: The commit
will still be aborted if there are
uncomitted to files with version strings.
--ignore-vcs-tag Ignore VCS tag invariant and update version
anyway.
--set-version <VERSION> Set version explicitly.
--date <ISODATE> Set explicit date in format YYYY-0M-0D (e.g.
2023-07-10).
--pin-date Leave date components unchanged.
--pin-increments Leave the auto-increments INC0 and INC1
unchanged.
--tag-num Increment release tag number (rc1, rc2,
rc3..).
-t, --tag <NAME> Override release tag of current_version.
Valid options are: alpha, beta, dev, rc,
post, final.
-p, --patch Increment PATCH component.
-m, --minor Increment MINOR component.
--major Increment MAJOR component.
-c, --commit-message <TMPL> Set commit message template.
--tag-message <TMPL> Set tag message template.
--commit / --no-commit Create a commit with all updated files.
--tag-commit / --no-tag-commit Tag the newly created commit.
--push / --no-push Push to the default remote.
--tag-scope [default|global|branch]
Tag scope for the current version.
--pre-commit-hook <PATH> Custom script that runs before the commit
step
--post-commit-hook <PATH> Custom script that runs after the commit
step is completed
-h, --help Show this message and exit.
```
<!-- END bumpver update --help -->
To help with shell script automation, you can use `bumpver show --environ`.
```shell
$ bumpver show -n --environ
YEAR_Y=2020
YEAR_G=
...
TAG=final
...
$ eval $(bumpver show -n --environ)
$ echo $TAG
final
```
### Part Overview
> Where possible, these patterns match the conventions from [CalVer.org][url_calver_org_scheme].
[url_calver_org_scheme]: https://calver.org/#scheme
| part | range / example(s) | info |
|------------|----------------------------|---------------------------------------------|
| `MAJOR` | 0..9, 10..99, 100.. | `bumpver update --major` |
| `MINOR` | 0..9, 10..99, 100.. | `bumpver update --minor` |
| `PATCH` | 0..9, 10..99, 100.. | `bumpver update --patch` |
| `TAG` | dev, alpha, beta, rc, post | `--tag=<tag>` |
| `PYTAG` | a, b, rc, post | `--tag=<tag>` |
| `NUM` | 0, 1, 2... | `-r/--tag-num` |
| `YYYY` | 2019, 2020... | Full year, based on `strftime('%Y')` |
| `YY` | 18, 19..99, 0, 1 | Short year, based on `int(strftime('%y'))` |
| `MM` | 9, 10, 11, 12 | Month, based on `int(strftime('%m'))` |
| `DD` | 1, 2, 3..31 | Day, based on `int(strftime('%d'))` |
| `BUILD` | 1001, 1002 .. 1999, 22000 | build number (maintains lexical order) |
| `INC0` | 0, 1, 2... | 0-based auto incrementing number |
| `INC1` | 1, 2... | 1-based auto incrementing number |
| `PYTAGNUM` | a0, a1, rc0, ... | `PYTAG` + `NUM` (no white-space in between) |
The following are also available, but you should review the [Normalization Caveats](#normalization-caveats) before you decide to use them.
| part | range / example(s) | comment |
| ------ | ------------------- | -------------------------------------------- |
| `Q` | 1, 2, 3, 4 | Quarter |
| `0Y` | 18, 19..99, 00, 01 | Short Year `strftime('%y')`(zero-padded) |
| `0M` | 09, 10, 11, 12 | Month `strftime('%m')` (zero-padded) |
| `0D` | 01, 02, 03..31 | Day `strftime('%d')` (zero-padded) |
| `JJJ` | 1,2,3..366 | Day of year `int(strftime('%j'))` |
| `00J` | 001, 002..366 | Day of year `strftime('%j')` (zero-padded) |
| `WW` | 0, 1, 2..52 | Week number¹ `int(strftime('%W'))` |
| `0W` | 00, 01, 02..52 | Week number¹ `strftime('%W')` (zero-padded) |
| `UU` | 0, 1, 2..52 | Week number² `int(strftime('%U'))` |
| `0U` | 00, 01, 02..52 | Week number² `strftime('%U')` (zero-padded) |
| `VV` | 1, 2..53 | Week number¹³ `int(strftime('%V'))` |
| `0V` | 01, 02..53 | Week number¹³ `strftime('%V')` (zero-padded) |
| `GGGG` | 2019, 2020... | `strftime("%G")` ISO 8601 week-based year |
| `GG` | 19, 20...99, 0, 1 | Short ISO 8601 week-based year |
| `0G` | 19, 20...99, 00, 01 | Zero-padded ISO 8601 week-based year |
- ¹ Monday is the first day of the week.
- ² Sunday is the first day of the week.
- ³ ISO 8601 week. Week 1 contains Jan 4th.
### Normalization Caveats
Package managers and installation tools will parse your version numbers. When doing so, your version number may go through a normalization process and may not be exactly as you specified. In the case of Python, the packaging tools (such as pip, twine, [setuptools][setuptools_ref]) follow [PEP440 normalization rules][pep_440_normalzation_ref].
According to these rules (among other things):
- Any non-numerical prefix (such as `v`) is removed
- Leading zeros in delimited parts are truncated `XX.08` -> `XX.8`
- Tags are converted to a short form (`-alpha` -> `a0`)
For example:
- Pattern: `vYY.0M.0D[-TAG]`
- Version: `v20.08.02-beta`
- PEP440 : `20.8.2b0`
I am not aware of any technical reason to use a normalized representation everywhere in your project. However, if you choose a pattern which is always in a normalized form, it will help to avoid confusion. For example, it may not be obvious at a glance, that `v20.08.02-beta` is the same as `20.8.2b0` .
A further consideration for the choice of your `version_pattern` is that it may be processed by tools that *do not* interpret it as a version number, but treat it just like any other string. It may also be confusing to your users if they a list of version numbers, sorted lexicographically by some tool (e.g. from `git tags`) and versions are not listed in order of their release:
```
$ git tag
18.6b4
18.9b0
19.10b0
19.3b0
20.8b0
20.8b1
```
If you wish to avoid this, you should use a pattern which maintains lexicographical ordering.
[setuptools_ref]: https://setuptools.readthedocs.io/en/latest/setuptools.html#specifying-your-project-s-version
[pep_440_normalzation_ref]: https://www.python.org/dev/peps/pep-0440/#id31
### Pattern Examples
<!-- BEGIN pattern_examples -->
| pattern | examples | PEP440 | lexico. |
|---------------------------------|-----------------------------------|--------|---------|
| `MAJOR.MINOR.PATCH[PYTAGNUM]` | `0.13.10 0.16.10` | yes | no |
| `MAJOR.MINOR[.PATCH[PYTAGNUM]]` | `0.11.15 0.16.18` | yes | no |
| `YYYY.BUILD[PYTAGNUM]` | `2020.1031 2020.1406` | yes | yes |
| `YYYY.BUILD[-TAG]` | `2021.1393-beta 2022.1279` | no | yes |
| `YYYY.INC0[PYTAGNUM]` | `2020.4b0 2020.16` | yes | no |
| `YYYY0M.PATCH[-TAG]` | `202210.10 202211.13-beta` | no | no¹ |
| `YYYY0M.BUILD[-TAG]` | `202005.1269-beta 202206.1056` | no | yes |
| `YYYY.0M` | `2020.01 2021.04` | no | yes |
| `YYYY.MM` | `2020.2 2022.2` | yes | no |
| `YYYY.WW` | `2020.33 2020.39` | yes | no |
| `YYYY.MM.PATCH[PYTAGNUM]` | `2022.3.1b0 2022.11.15b0` | yes | no |
| `YYYY.0M.PATCH[PYTAGNUM]` | `2020.03.2 2022.02.4` | no | no¹ |
| `YYYY.MM.INC0` | `2020.7.10 2021.7.7` | yes | no |
| `YYYY.MM.DD` | `2020.8.9 2020.8.20` | yes | no |
| `YYYY.0M.0D` | `2020.11.02 2022.05.03` | no | yes |
| `YY.0M.PATCH` | `20.05.12 22.03.5` | no | no² |
<!-- END pattern_examples -->
- ¹ If `PATCH > 9`
- ² For the year 2100, the part `YY` will produce 0
### Week Numbering
Week numbering is a bit special, as it depends on your definition of "week":
- First day of the week is either Monday or Sunday.
- Range either from 0-52 or 1-53.
- At the beginning/end of the year, you either have partial weeks or a week that spans multiple years.
If you use `VV`/`0V`, be aware that you cannot also use `YYYY`.
Instead use `GGGG`. This is to avoid an edge case where your version
number would run backwards if it was created around New Year.
<!-- BEGIN weeknum_example -->
```
YYYY WW UU GGGG VV
2020-12-26 (Sat): 2020 51 51 2020 52
2020-12-27 (Sun): 2020 51 52 2020 52
2020-12-28 (Mon): 2020 52 52 2020 53
2020-12-29 (Tue): 2020 52 52 2020 53
2020-12-30 (Wed): 2020 52 52 2020 53
2020-12-31 (Thu): 2020 52 52 2020 53
2021-01-01 (Fri): 2021 00 00 2020 53
2021-01-02 (Sat): 2021 00 00 2020 53
2021-01-03 (Sun): 2021 00 01 2020 53
2021-01-04 (Mon): 2021 01 01 2021 01
```
<!-- END weeknum_example -->
## Configuration
### Configuration Setup
The create an initial configuration for project with `bumpver init`.
```shell
$ pip install bumpver
...
Installing collected packages: click toml lexid bumpver
Successfully installed bumpver-2024.1130
$ cd myproject
~/myproject/
$ bumpver init --dry
Exiting because of '-d/--dry'. Would have written to bumpver.toml:
[bumpver]
current_version = "2020.1001a0"
version_pattern = "YYYY.BUILD[PYTAGNUM]"
commit_message = "bump version to {new_version}"
tag_message = "{new_version}"
tag_scope = "default"
pre_commit_hook = ""
post_commit_hook = ""
commit = true
tag = true
push = true
[bumpver.file_patterns]
"README.md" = [
"{version}",
"{pep440_version}",
]
"bumpver.toml" = [
'current_version = "{version}"',
]
```
If you already have configuration file in your project (such as `setup.cfg` or `pyproject.toml`), then `bumpver init` will update that file instead.
```
~/myproject
$ bumpver init
Updated pyproject.toml
```
Your `pyproject.toml` may now look something like this:
```ini
[bumpver]
current_version = "2019.1001-alpha"
version_pattern = "YYYY.BUILD[-TAG]"
commit_message = "bump version to {new_version}"
tag_message = "{new_version}"
tag_scope = "default"
pre_commit_hook = ""
post_commit_hook = ""
commit = true
tag = true
push = true
[bumpver.file_patterns]
"pyproject.toml" = [
'current_version = "{version}"',
]
"setup.py" = [
'version="{pep440_version}",',
]
"README.md" = [
'{version}',
'{pep440_version}',
]
```
### Debugging Configuration
For the entries in `[bumpver:file_patterns]` you can expect two failure modes:
- False negative: A pattern *will not* match a version number in the associated file *which it should* match.
- False positive: A pattern *will* match something it *should not match* (less likely).
Most obviously you will see such cases when you first attempt to use `bumpver update`:
```shell
$ bumpver update --dry --no-fetch
INFO - Old Version: 2020.1001-alpha
INFO - New Version: 2020.1002-alpha
ERROR - No match for pattern 'version="YYYY.BUILD[PYTAGNUM]",'
ERROR -
# https://regex101.com/?flavor=python&flags=gmx®ex=version%3D%5C%22%0A%28%3FP%3Cyear_y%3E%5B1-9%5D%5B0-9%5D%7B3%7D%29%0A%5C.%0A%28%3FP%3Cbid%3E%5B1-9%5D%5B0-9%5D%2A%29%0A%28%3F%3A%0A%20%20%20%20%28%3FP%3Cpytag%3Epost%7Crc%7Ca%7Cb%29%0A%20%20%20%20%28%3FP%3Cnum%3E%5B0-9%5D%2B%29%0A%29%3F%0A%5C%22%2C
regex = re.compile(r"""
version=\"
(?P<year_y>[1-9][0-9]{3})
\.
(?P<bid>[1-9][0-9]*)
(?:
(?P<pytag>post|rc|a|b)
(?P<num>[0-9]+)
)?
\",
""", flags=re.VERBOSE)
ERROR - No patterns matched for file 'setup.py'
```
The internally used regular expression is also shown, which you can use to debug the issue, for example on [regex101.com](https://regex101.com/r/ajQDTz/2).
To debug such issues, you can simplify your pattern and see if you can find a match with `bumpver grep` .
```shell
$ bumpver grep 'YYYY.BUILD[PYTAGNUM]' setup.py
45: name='myproject',
46: version='2019.1001b0',
47: license='MIT',
```
Here we can see that the pattern for setup.py should be changed to used single quotes instead of doublequotes.
As with `bumpver update`, if your pattern is not found, `bumpver grep` will show an error message with the regular expression it uses, to help you debug the issue.
```shell
$ bumpver grep 'YYYY.BUILD[PYTAGNUM]' setup.py
ERROR - Pattern not found: 'YYYY.BUILD[PYTAGNUM]'
# https://regex101.com/...
```
An example of a more complex pattern is one where you want to keep a version badge in your README up to date.
```shell
$ bumpver grep 'shields.io/badge/CalVer-YYYY.BUILD[--TAG]-blue' README.md
61:
62: [img_version]: https://img.shields.io/badge/CalVer-2020.1001--beta-blue
63: [url_version]: https://pypi.org/org/package/
```
## Bump It Up
### Version State
The `current_version` is considered global state and must be stored somewhere. Typically this might be in a `VERSION` file, or some other file which is part of the repository. This creates the risk that parallel branches can have different states. If the `current_version` were defined only by files in the local checkout, the same version might be generated on different systems for different commits.
To avoid this issue, `bumpver` treats Git/Mercurial tags as a second source, depending on the `tag_scope` option, for the most recent version and attempts to change this state in the most atomic way possible. This is why some actions of the `bumpver` command can take a few seconds, as it is synchronizing with the remote repository to get the most recent versions and to push any new version tags as soon as possible.
### The Current Version
The current version depends on the configured `tag_scope` and is either
| `tag_scope =` | `current_version =` |
|---------------|-----------------------------------------------------|
| `default` | `max(config.current_version, max(global_vcs_tags))` |
| `global` | `max(global_vcs_tags)` |
| `branch` | `max(branch_vcs_tags)` |
- Before any tags have been created `bumpver` will always default to the value of `current_version` in `bumpver.toml` / `setup.cfg` / `pyproject.toml`.
- Only Git/Mercurial tags which matches the `version_pattern` from your config will be considered and sorted using [`pkg_resources.parse_version`][url_setuptools_pkg_resources].
[url_setuptools_pkg_resources]: https://setuptools.readthedocs.io/en/latest/pkg_resources.html#parsing-utilities
As part of doing `bumpver update` and `bumpver show`, your local tags are updated using `git fetch --tags`/`hg pull`.
```shell
$ bumpver show -vv
2020-10-18T20:20:58.062 DEBUG bumpver.cli - Logging configured.
2020-10-18T20:20:58.065 DEBUG bumpver.config - Config Parsed: Config(
...
2020-10-18T20:20:58.067 DEBUG bumpver.vcs - vcs found: git
2020-10-18T20:20:58.067 INFO bumpver.vcs - fetching tags from remote (to turn off use: -n / --no-fetch)
2020-10-18T20:20:58.068 DEBUG bumpver.vcs - git fetch
2020-10-18T20:21:00.886 DEBUG bumpver.vcs - git tag --list
2020-10-18T20:21:00.890 INFO bumpver.cli - Latest version from git tag: 2020.1019
Current Version: 2020.1019
```
Here we see that:
- Git had a newer version than we had locally (`2020.1019` vs `2020.1018`).
- It took 2 seconds to fetch the tags from the remote repository.
The approach of fetching tags before the version is bumped/incremented, helps to reduce the risk that the newest tag is not known locally. This means that it less likely for the same version to be generated by different systems for different commits. This would result in an ambiguous version tag, which may not be the end of the world, but is better to avoid. Typically this might happen if you have a build system where multiple builds are triggered at the same time.
For a small project (with only one maintainer and no automated packaging) this is a non-issue and you can always use `-n/--no-fetch` to skip fetching the tags.
### Dry Mode
Once you have a valid configuration, you can use `bumpver update --dry` to see the changes it would make (and leave your project files untouched).
```diff
$ bumpver update --dry --no-fetch
INFO - Old Version: 2019.1001-beta
INFO - New Version: 2019.1002-beta
--- README.md
+++ README.md
@@ -11,7 +11,7 @@
[![Supported Python Versions][pyversions_img]][pyversions_ref]
-[![Version 2019.1001-beta][version_img]][version_ref]
+[![Version 2019.1002-beta][version_img]][version_ref]
[![PyPI Releases][pypi_img]][pypi_ref]
--- src/mymodule_v1/__init__.py
+++ src/mymodule_v1/__init__.py
@@ -1,1 +1,1 @@
-__version__ = "2019.1001-beta"
+__version__ = "2019.1002-beta"
--- src/mymodule_v2/__init__.py
+++ src/mymodule_v2/__init__.py
@@ -1,1 +1,1 @@
-__version__ = "2019.1001-beta"
+__version__ = "2019.1002-beta"
--- setup.py
+++ setup.py
@@ -44,7 +44,7 @@
name="myproject",
- version="2019.1001b0",
+ version="2019.1002b0",
license="MIT",
```
### VCS Parameters (git/mercurial)
The individual steps performed by `bumpver update`:
1. *Fetch* VCS tags from origin.
2. Get most recent version.
3. Generate the updated version string.
4. Check that you have no local changes that are uncommitted.
5. Replace version strings in all files configured in `file_patterns`.
6. Run pre-commit hook.
7. *Commit* the updated files.
8. Run post-commit hook.
9. *Tag* the new commit.
10. *Push* the new commit and tag.
The configuration for these steps can be done with the following parameters:
| Parameter | Type | Description |
|--------------------|----------|--------------------------------------------|
| `tag_scope` | string | Scope for the `current_version` in step 2. |
| `commit_message` | string¹ | Template for commit message in step 6. |
| `tag_message` | string¹ | Template for tag message in step 9. |
| `pre_commit_hook` | string² | Path to the pre-commit script. |
| `commit` | boolean | Create a commit with all updated files. |
| `post_commit_hook` | string² | Path to the post-commit script. |
| `tag` | boolean² | Tag the newly created commit. |
| `push` | boolean² | Push to the default remote. |
- ¹ Available template placeholders: `{new_version}`, `{old_version}`, `{new_version_pep440}`, `{old_version_pep440}`
- ² Requires `commit = True`
An example configuration might look like this:
```ini
[bumpver]
...
commit_message = "bump version to {new_version}"
tag_message = "{new_version}"
tag_scope = "default"
pre_commit_hook = "scripts/run_checks.sh"
post_commit_hook = "scripts/update_changelog.sh"
commit = True
tag = True
push = True
```
If everything looks OK, you can do `bumpver update`.
```shell
$ bumpver update --verbose
INFO - fetching tags from remote (to turn off use: -n / --no-fetch)
INFO - Old Version: 2020.1005
INFO - New Version: 2020.1006
INFO - Run pre-commit hook: scripts/run_checks.sh
INFO - ...
INFO - git commit --message 'bump version to 2020.1006'
INFO - Run post-commit hook: scripts/update_changelog.sh
INFO - ...
INFO - git tag --annotate 2020.1006 --message 2020.1006
INFO - git push origin --follow-tags 2020.1006 HEAD
```
You can also override the config values by passing these command line flags to `bumpver update`:
| Flag | Override config |
|-------------------|-------------------------------------------------|
| `--commit` | `commit = True` |
| `--no-commit` | `commit = False`, `tag = False`, `push = False` |
| `--tag-commit` | `tag = True` |
| `--no-tag-commit` | `tag = False` |
| `--push` | `push = True` |
| `--no-push` | `push = False` |
### Custom Commit Message
In addition to the `commit_message` configuration, you can also override the string used as the the commit message template with the `-c/--commit-message=<TMPL>` parameter:
```shell
$ bumpver update --tag final --commit-message 'bump version {old_version} -> {new_version} [ci-publish]' --verbose
INFO - Old Version: 2021.1005b0
INFO - New Version: 2021.1006
INFO - git commit --message 'bump version 2020.1005b0 -> 2021.1006 [ci-publish]'
INFO - git tag --annotate 2020.1006 --message '2020.1006'
INFO - git push origin --follow-tags 2020.1006 HEAD
```
As this is a manual operation (rather than a long lived configuration option), you can use the placeholders `OLD` and `NEW` for convenience, instead of the more verbose `{old_version}` and `{new_version}`.
```shell
$ bumpver update -f -t final -c '[final-version] OLD -> NEW'
...
INFO - Old Version: 1.2.0b2
INFO - New Version: 1.2.0
INFO - git commit --message '[final-version] 1.2.0b2 -> 1.2.0'
...
```
### Custom Tag Message
Similarly to `--commit-message` you can provide a tag message template by using the `--tag-message=<TMPL>` parameter or the `tag_message` configuration:
```shell
$ bumpver update -f -t final --tag-message 'release NEW'
INFO - Old Version: 1.2.0b2
INFO - New Version: 1.2.0
...
INFO - git tag --annotate 1.2.0 --message 'release 1.2.0'
...
```
You can use the same placeholders as in the `--commit-message` template.
If an empty tag message is provided, bumpver uses a lightweight tag in Git. Otherwise, it utilizes an annotated Git tag. You can read more about Git tagging [here](https://git-scm.com/book/en/v2/Git-Basics-Tagging).
```shell
$ bumpver update -f -t final --tag-message ''
INFO - Old Version: 1.2.0b2
INFO - New Version: 1.2.0
...
INFO - git tag 1.2.0
...
```
### Pre/Post-Commit Hooks
`Bumpver` allows you to run custom scripts *before* and *after* the commit step using the `--pre-commit-hook=<PATH>` and `--post-commit-hook=<PATH>` parameter, respectively their configuration counterparts `pre_commit_hook` and `post_commit_hook`. Both options require `commit=True` to be set and the `<PATH>` must be either absolute or relative to the working dir.
If a script fails (exits with a `return_code!=0`) `bumpver` aborts and all subsequent steps won't be executed, e.g. *commit*, *tag* and *push*.
For your convenience there are two environment variables available which can be used in the scripts: `BUMPVER_OLD_VERSION` and `BUMPVER_NEW_VERSION`.
Example:
```python
#!/usr/bin/env python
# File path: scripts/print_new_version.py
from os import environ
print("The new version is " + environ.get('BUMPVER_NEW_VERSION', ''))
```
```
$ bumpver update --post-commit-hook scripts/print_new_version.py
INFO - fetching tags from remote (to turn off use: -n / --no-fetch)
INFO - Old Version: 2023.1001-alpha
INFO - New Version: 2023.1002-alpha
INFO - git commit --message 'bump version 2023.1001-alpha -> 2023.1002-alpha'
INFO - Run post-commit hook: scripts/print_new_version.py
INFO - The new version is 2023.1002-alpha
INFO - git tag --annotate 2023.1002-alpha --message '2023.1002-alpha'
INFO - git push origin --follow-tags 2023.1002-alpha HEAD
```
Make sure your script is executable, otherwise you might be greeted with:
```
$ bumpver update --post-commit-hook scripts/print_new_version.py
...
INFO - Run post-commit hook: scripts/print_new_version.py
ERROR - [Errno 13] Permission denied: 'scripts/print_new_version.py'
ERROR - Script exited with an error. Stopping
```
## Contributors
| Name | role | since | until |
|-------------------------------------|-------------------|---------|-------|
| Manuel Barkhau (mbarkhau@gmail.com) | author/maintainer | 2018-09 | - |
# Changelog for https://github.com/mbarkhau/bumpver
## BumpVer 2024.1130
This update adds the vendored module `setuptools_v65_version.py` from `setuptools==v65.7.0`.
This was the last version with support for `LegacyVersion`.
- Fix [#242][gh_i242]: Fix incorrect parsing of versions with tags.
- Fix [#156][gh_i156]: Remove runtime dependency on setuptools and looseversion.
[gh_i242]: https://github.com/mbarkhau/bumpver/issues/242
[gh_i156]: https://github.com/mbarkhau/bumpver/issues/156
Thank you [Andrew Mitchell](https://github.com/MitchellAcoustics) and [Tzu-Ting](https://github.com/tzing) for your issue reports.
## BumpVer 2023.1129
- Fix [#224][gh_i224]: Add `--environ` so it emits `0` values. Depricate `-e/--env`.
- Add [#223][gh_pr223]: Add support for `.bumpver.toml`
[gh_i224]: https://github.com/mbarkhau/bumpver/issues/224
[gh_pr223]: https://github.com/mbarkhau/bumpver/pull/223
Thank you [Adrianne](https://github.com/elfgirl) for this issue report.
Thank you [Xavier Francisco](https://github.com/XF-FW) for your contribution.
## BumpVer 2023.1127
- Add [#222][gh_pr222]: Add part HEXHASH.
[gh_pr222]: https://github.com/mbarkhau/bumpver/pull/222
Thank you [Atwam](https://github.com/atwam) for your contribution.
## BumpVer 2023.1126
- Add [#214][gh_pr214]: Support for pre/post commit hooks.
- Add [#219][gh_pr219]: Fix pathlib issues on Windows.
- Fix [#201][gh_i201]: Better error message for SemVer corner case.
- Update [#215][gh_i215]: Better error message for greedy pattern matching.
- Update [#216][gh_i216]: Use .toml format in REAMDE examples.
[gh_pr214]: https://github.com/mbarkhau/bumpver/pull/214
[gh_pr219]: https://github.com/mbarkhau/bumpver/pull/219
[gh_i201]: https://github.com/mbarkhau/bumpver/issues/201
[gh_i215]: https://github.com/mbarkhau/bumpver/issues/215
[gh_i216]: https://github.com/mbarkhau/bumpver/issues/216
Thank you [Sven Lohrmann](https://github.com/malnvenshorn) for your contribution.
Thank you [Maikel Punie](https://github.com/Cereal2nd) your issue report.
Thank you for your help in debugging Windows issues:
- [Søren Furbo](https://github.com/SRFU-NN)
- [Michal Vašut](https://github.com/MichalVasut)
- [Justin Cooksey](https://github.com/jscooksey)
- [yqbear](https://github.com/yqbear)
## BumpVer 2023.1125
- Add [#188][gh_i188]: Add `--tag-scope=<SCOPE>` to support separate versioning for branches.
- Add [#185][gh_i185]: Add `--tag-message=<TMPL>` parameter and `tag_message` configuration option.
- Fix [#209][gh_i209]: Make `--no-tag-commit` ommit `--follow-tags`.
[gh_i188]: https://github.com/mbarkhau/bumpver/issues/188
[gh_i185]: https://github.com/mbarkhau/bumpver/issues/185
[gh_i209]: https://github.com/mbarkhau/bumpver/issues/209
Thank you [Sven Lohrmann](https://github.com/malnvenshorn) for your contributions.
Thank you [tardis4500](https://github.com/tardis4500) for the issue report.
## BumpVer 2023.1124
- Fix [#208][gh_i208]: Fix handling of versions with PEP440 epoch.
[gh_i208]: https://github.com/mbarkhau/bumpver/issues/208
Thank you [Wen Kokke](https://github.com/wenkokke) for the issue report.
## BumpVer 2023.1122
- Fix [#207][gh_i207]: Add --ignore-vcs-tag to support bumping older versions
[gh_i207]: https://github.com/mbarkhau/bumpver/issues/207
Thank you [Jusong Yu](https://github.com/unkcpz) for your contribution.
## BumpVer 2023.1121
- Fix [#200][gh_i200]: Fix compatability with packaging 23.0.
- Fix [#203][gh_i203]: Add dev to the list of valid release tags
[gh_i200]: https://github.com/mbarkhau/bumpver/issues/200
[gh_i203]: https://github.com/mbarkhau/bumpver/issues/203
Thank you [Sharon Yogev](https://github.com/sharonyogev) for your contribution.
## BumpVer 2022.1120
- Fix [#196][gh_i196]: Add `--pin-increments`.
[gh_i196]: https://github.com/mbarkhau/bumpver/issues/196
Thank you [Markus Holtermann](https://github.com/MarkusH) for
this contribution.
## BumpVer 2022.1119
- Fix [#190][gh_i190]: Allow multiple patterns on the same line
- Fix [#182][gh_i182]: Use quotes for vcs commands
[gh_i190]: https://github.com/mbarkhau/bumpver/issues/190
[gh_i182]: https://github.com/mbarkhau/bumpver/issues/182
## BumpVer 2022.1118
- Fix [#181][gh_i181]: Enable use of ``^$`` charachters to restrict
matching to beginning and end of line.
- Add ``GITHASH`` to ``version_pattern`` (@mpasternak)
[gh_i181]: https://github.com/mbarkhau/bumpver/issues/181
## BumpVer 2022.1116
- Fix: [incorrect version comparison when updating from vcs tag][gh_i174].
When comparing the updated version to the latest vcs tag,
an insufficient string comparison was used instead of
comparing the parsed versions.
[gh_i174]: https://github.com/mbarkhau/bumpver/issues/174
Thank you to Timo Ludwig @timoludwig for this contribution.
## BumpVer 2022.1115
- Fix: [use default date values][gh_i172].
When parsing the current version, if it doesn't specify anyt
date part, (such as is the case for e.g. SemVer), then use the
current date to populate default parts.
This enables updating YYYY patterns in copyright headers even
for projects that don't use a CalVer pattern.
Thank you [Benjamin Depardon (@bdepardo)][gh_bdepardo] for
finding and reporting this issue.
[gh_i172]: https://github.com/mbarkhau/bumpver/issues/172
[gh_bdepardo]: https://github.com/bdepardo
## BumpVer 2021.1114
- Add: [flags to override vcs options][gh_i168] for `bumpver update`
[gh_i168]: https://github.com/mbarkhau/bumpver/issues/168
Thank you to Timo Ludwig @timoludwig for this contribution.
## BumpVer 2021.1113
- Add: [`--commit-message` argument][gh_i162] for `bumpver update`
[gh_i162]: https://github.com/mbarkhau/bumpver/issues/162
## BumpVer 2021.1112
- Fix: Build from source on windows.
## BumpVer 2021.1110
- Fix [github#157][gh_i157]: Improve error messages.
- Fix [github#158][gh_i158]: Clarify `PYTAGNUM` "part"
[gh_i157]: https://github.com/mbarkhau/bumpver/issues/157
[gh_i158]: https://github.com/mbarkhau/bumpver/issues/158
Thank you to Julien Palard @JulienPalard for testing and feedback.
## BumpVer 2021.1109
- Add `-e/--env` option to support shell script automation.
- Fix [github#151][gh_i151]: invalid increment of `TAGNUM` when `TAG=final` is set.
[gh_i151]: https://github.com/mbarkhau/bumpver/issues/151
Thank you to Dave Wapstra @dwapstra for your contributions.
## BumpVer 2020.1108
- Don't match empty patterns (possibly causing a whole file to be rewritten if braces `[]` are not escaped).
## BumpVer 2020.1107
- Non-Beta release (no significant code changes).
## BumpVer 2020.1105-beta
- Fix [gitlab#15][gitlab_i15]: Fix config parsing corner case.
- Fix [gitlab#16][gitlab_i16]: Fix rollover handling for tag/pytag.
[gitlab_i15]: https://gitlab.com/mbarkhau/pycalver/-/issues/15
[gitlab_i16]: https://gitlab.com/mbarkhau/pycalver/-/issues/16
## BumpVer 2020.1104-beta
- Fix [gitlab#13][gitlab_i13]: Add `--set-version=<VERSION>` to explicitly set version.
- Fix [gitlab#14][gitlab_i14]: Parse `tool.bumpver` when using pyproject.toml as per PEP 518.
[gitlab_i13]: https://gitlab.com/mbarkhau/pycalver/-/issues/13
[gitlab_i14]: https://gitlab.com/mbarkhau/pycalver/-/issues/14
## BumpVer 2020.1100-beta
Rename package and module from PyCalVer to BumpVer. This name change is due to confusion that this project is either Python specific, or only suitible for CalVer versioning schemes, neither of which is the case.
This release includes a new syntax for patterns.
```
version_pattern = "vYYYY0M.BUILD[-RELEASE]" # new style
version_pattern = "v{year}{month}{build}{release}" # old style
version_pattern = "MAJOR.MINOR.PATCH" # new style semver
version_pattern = "{MAJOR}.{MINOR}.{PATCH}" # old style semver
```
The main reasons for this switch were:
- To enable optional parts using braces `[PART]`.
- To align the syntax with the conventions used on CalVer.org
The previous syntax will continue to be supported, but all documentation has been updated to primarily reference new style patterns.
- Switch main repo from gitlab to github.
- New [gitlab#7][gitlab_i7]: New style pattern syntax.
- Better support for week numbers.
- Better support for optional parts.
- New: `BUILD` part now starts at `1000` instead of `0001` to avoid truncation of leading zeros.
- New: Add `INC0` (0-based) and `INC1` (1-based) parts that do auto increment and rollover.
- New: `MAJOR`/`MINOR`/`PATCH`/`INC` will roll over when a date part changes to their left.
- New [gitlab#2][gitlab_i2]: Added `grep` sub-command to help with debugging of patterns.
- New [gitlab#10][gitlab_i10]: `--pin-date` to keep date parts unchanged, and only increment non-date parts.
- New: Added `--date=<iso-date>` parameter to set explicit date (instead of current date).
- New: Added `--release-num` to increment the `alphaN`/`betaN`/`a0`/`b0`/etc. release number
- New: Added better error messages to debug regular expressions.
- New [gitlab#9][gitlab_i9]: Make commit message configurable.
- Fix [gitlab#12][gitlab_i12]: Error with sorting non-lexical version tags (e.g. SemVer).
- Fix [gitlab#11][gitlab_i11]: Show regexp when `--verbose` is used.
- Fix [gitlab#8][gitlab_i8]: `bumpver update` will now also push HEAD (previously only the tag itself was pushed).
- Fix: Disallow `--release=dev`. The semantics of a `dev` releases are different than for other release tags and further development would be required to support them correctly.
- Fix: Entries in `file_patterns` were ignored if there were multiple entries for the same file.
This release no longer includes the `pycalver.lexid` module, which has been moved into its own package: [pypi.org/project/lexid/](https://pypi.org/project/lexid/).
Many thanks to contributors of this release: @LucidOne, @khanguslee, @chaudum
[gitlab_i7]:https://gitlab.com/mbarkhau/pycalver/-/issues/7
[gitlab_i2]: https://gitlab.com/mbarkhau/pycalver/-/issues/2
[gitlab_i10]: https://gitlab.com/mbarkhau/pycalver/-/issues/10
[gitlab_i9]: https://gitlab.com/mbarkhau/pycalver/-/issues/9
[gitlab_i12]: https://gitlab.com/mbarkhau/pycalver/-/issues/12
[gitlab_i11]: https://gitlab.com/mbarkhau/pycalver/-/issues/11
[gitlab_i8]: https://gitlab.com/mbarkhau/pycalver/-/issues/8
## PyCalVer v202010.1042
- Add deprication warning to README.md
## PyCalVer v201907.0036
- Fix: Don't use git/hg command if `commit=False` is configured (thanks @valentin87)
## PyCalVer v201907.0035
- Fix [gitlab#6][gitlab_i6]: Add parts `{month_short}`, `{dom_short}`, `{doy_short}`.
- Fix [gitlab#5][gitlab_i5]: Better warning when using bump with SemVer (one of --major/--minor/--patch is required)
- Fix [gitlab#4][gitlab_i4]: Make {release} part optional, so that versions generated by --release=final are parsed.
[gitlab_i6]: https://gitlab.com/mbarkhau/pycalver/-/issues/6
[gitlab_i5]: https://gitlab.com/mbarkhau/pycalver/-/issues/5
[gitlab_i4]: https://gitlab.com/mbarkhau/pycalver/-/issues/4
## PyCalVer v201903.0030
- Fix: Use pattern from config instead of hard-coded {pycalver} pattern.
- Fix: Better error messages for git/hg issues.
- Add: Implicit default pattern for config file.
## PyCalVer v201903.0028
- Fix: Add warnings when configured files are not under version control.
- Add: Colored output for bump --dry
## PyCalVer v201902.0027
- Fix: Allow --release=post
- Fix: Better error reporting for bad patterns
- Fix: Regex escaping issue with "?"
## PyCalVer v201902.0024
- Added: Support for globs in file patterns.
- Fixed: Better error reporting for invalid config.
## PyCalVer v201902.0020
- Added: Support for many more custom version patterns.
## PyCalVer v201812.0018
- Fixed: Better handling of pattern replacements with "-final" releases.
## PyCalVer v201812.0017
- Fixed [github#2]. `pycalver init` was broken.
- Fixed pattern escaping issues.
- Added lots more tests for cli.
- Cleaned up documentation.
[gihlab_i2]: https://github.com/mbarkhau/pycalver/-/issues/2
## PyCalVer v201812.0011-beta
- Add version tags using git/hg.
- Use git/hg tags as SSOT for most recent version.
- Start using https://gitlab.com/mbarkhau/bootstrapit
- Move to https://gitlab.com/mbarkhau/pycalver
## PyCalVer v201809.0001-alpha
- Initial release
Raw data
{
"_id": null,
"home_page": "https://github.com/mbarkhau/bumpver",
"name": "bumpver",
"maintainer": null,
"docs_url": null,
"requires_python": ">=2.7",
"maintainer_email": null,
"keywords": "version bumpver calver semver versioning bumpversion pep440",
"author": "Manuel Barkhau",
"author_email": "mbarkhau@gmail.com",
"download_url": "https://files.pythonhosted.org/packages/bb/a9/becf78cc86211bd2287114c4f990a3bed450816696f14810cc59d7815bb5/bumpver-2024.1130.tar.gz",
"platform": null,
"description": "<div align=\"center\">\n<p align=\"center\">\n <img alt=\"logo\" src=\"https://raw.githubusercontent.com/mbarkhau/bumpver/master/bumpver_128.png\">\n</p>\n</div>\n\n\n# [BumpVer: Automatic Versioning][url_repo]\n\nWith the CLI command `bumpver`, you can search for and update version strings in your project files. It has a flexible pattern syntax to support many version schemes ([SemVer][url_semver_org], [CalVer][url_calver_org] or otherwise). BumpVer features:\n\n- Configurable version patterns\n- Optional Git or Mercurial integration\n- Works with plaintext, so you can use it with any project.\n\n[url_repo]: https://github.com/mbarkhau/bumpver\n[url_semver_org]: https://semver.org/\n[url_calver_org]: https://calver.org/\n\n\nProject/Repo:\n\n[![MIT License][img_license]][url_license]\n[![Supported Python Versions][img_pyversions]][url_pyversions]\n[![CalVer 2024.1130][img_version]][url_version]\n[![PyPI Releases][img_pypi]][url_pypi]\n[![PyPI Downloads][img_downloads]][url_downloads]\n\nCode Quality/CI:\n\n[![GitHub Build Status][img_github_build]][url_github_build]\n[![GitLab Build Status][img_gitlab_build]][url_gitlab_build]\n[![Type Checked with mypy][img_mypy]][url_mypy]\n[![Code Coverage][img_codecov]][url_codecov]\n[![Code Style: sjfmt][img_style]][url_style]\n\n\n[img_github_build]: https://github.com/mbarkhau/pycalver/workflows/CI/badge.svg\n[url_github_build]: https://github.com/mbarkhau/pycalver/actions?query=workflow%3ACI\n\n[img_gitlab_build]: https://gitlab.com/mbarkhau/pycalver/badges/master/pipeline.svg\n[url_gitlab_build]: https://gitlab.com/mbarkhau/pycalver/pipelines\n\n[img_codecov]: https://gitlab.com/mbarkhau/pycalver/badges/master/coverage.svg\n[url_codecov]: https://mbarkhau.gitlab.io/pycalver/cov\n\n[img_license]: https://img.shields.io/badge/License-MIT-blue.svg\n[url_license]: https://github.com/mbarkhau/bumpver/blob/master/LICENSE\n\n[img_mypy]: https://img.shields.io/badge/mypy-checked-green.svg\n[url_mypy]: https://mbarkhau.gitlab.io/pycalver/mypycov\n\n[img_style]: https://img.shields.io/badge/code%20style-%20sjfmt-f71.svg\n[url_style]: https://gitlab.com/mbarkhau/straitjacket/\n\n[img_downloads]: https://pepy.tech/badge/bumpver/month\n[url_downloads]: https://pepy.tech/project/bumpver\n\n[img_version]: https://img.shields.io/static/v1.svg?label=CalVer&message=2024.1130&color=blue\n[url_version]: https://pypi.org/project/bumpver/\n\n[img_pypi]: https://img.shields.io/badge/PyPI-wheels-green.svg\n[url_pypi]: https://pypi.org/project/bumpver/#files\n\n[img_pyversions]: https://img.shields.io/pypi/pyversions/bumpver.svg\n[url_pyversions]: https://pypi.python.org/pypi/bumpver\n\n<!--\n $ pip install -U md-toc\n $ md_toc --in-place --skip-lines 10 github README.md\n-->\n\n<!--TOC-->\n\n- [Overview](#overview)\n - [Search and Replace](#search-and-replace)\n - [Name Change PyCalVer -> BumpVer](#name-change-pycalver---bumpver)\n - [Related Projects/Alternatives](#related-projectsalternatives)\n- [Example Usage](#example-usage)\n - [Testing a `version_pattern`](#testing-a-version_pattern)\n - [Using `MAJOR`/`MINOR`/`PATCH` (SemVer Parts)](#using-majorminorpatch-semver-parts)\n - [Auto Increment Parts: `BUILD`/`INC0`/`INC1`](#auto-increment-parts-buildinc0inc1)\n - [Persistent Parts: `BUILD`/`TAG`/`PYTAG`](#persistent-parts-buildtagpytag)\n - [Searching for Patterns with `grep`](#searching-for-patterns-with-grep)\n- [Reference](#reference)\n - [Command Line](#command-line)\n - [Part Overview](#part-overview)\n - [Normalization Caveats](#normalization-caveats)\n - [Pattern Examples](#pattern-examples)\n - [Week Numbering](#week-numbering)\n- [Configuration](#configuration)\n - [Configuration Setup](#configuration-setup)\n - [Debugging Configuration](#debugging-configuration)\n- [Bump It Up](#bump-it-up)\n - [Version State](#version-state)\n - [The Current Version](#the-current-version)\n - [Dry Mode](#dry-mode)\n - [VCS Parameters (git/mercurial)](#vcs-parameters-gitmercurial)\n\n<!--TOC-->\n\n\n## Overview\n\n### Search and Replace\n\nWith `bumpver`, you configure a single `version_pattern` which is then used to\n\n1. Search for version strings in your project files\n2. Replace these with an updated/bumped version number.\n\nYour configuration might look something like this:\n\n```\n# pyproject.toml\n[bumpver]\ncurrent_version = \"1.5.2\"\nversion_pattern = \"MAJOR.MINOR.PATCH\"\n\n[bumpver.file_patterns]\n\"setup.py\" = [\n 'version=\"{version}\",$',\n]\n\"src/mymodule/__init__.py\" = [\n '^__version__ = \"{version}\"$',\n]\n```\n\nUsing this configuration, the output of `bumpver update --dry` might look something like this:\n\n```diff\n$ bumpver update --patch --dry\nINFO - Old Version: 1.5.2\nINFO - New Version: 1.5.3\n--- setup.py\n+++ setup.py\n@@ -63,7 +63,7 @@\n name=\"mymodule\",\n- version=\"1.5.2\",\n+ version=\"1.5.3\",\n description=description,\n\n--- src/mymodule/__init__.py\n+++ src/mymodule/__init__.py\n@@ -3,3 +3,3 @@\n\n-__version__ = \"1.5.2\"\n+__version__ = \"1.5.3\"\n```\n\n\n### Name Change PyCalVer -> BumpVer\n\nThis project was originally developed under the name PyCalVer, with the intent to support various CalVer schemes. The package has since been renamed from PyCalVer to BumpVer and the CLI command from `pycalver` to `bumpver`.\n\nThis name change is to reduce confusion that this project is only suitable for Python projects or only for CalVer versioning schemes, neither of which is the case.\n\n\n### Related Projects/Alternatives\n\nIf you are looking for an alternative, BumpVer was heavily influenced by [bumpversion/bump2version][url_bump2version]. You may also wish to take a look at their list of related projects: [bump2version/RELATED.md][url_bump2version_related]\n\n[url_bump2version]: https://github.com/c4urself/bump2version/\n[url_bump2version_related]: https://github.com/c4urself/bump2version/blob/master/RELATED.md\n\n\n## Example Usage\n\nYou can override the date used by `bumpver` with the `--date=<isodate>` option. Adding this every time would be distracting, so the examples assume the following date:\n\n```shell\n$ date --iso\n2020-10-15\n```\n\n\n### Testing a `version_pattern`\n\nTo test a `version_pattern` and how to increment it, you can use `bumpver test`:\n\n```shell\n$ bumpver test 'v2020.37' 'vYYYY.WW'\nNew Version: v2020.41\n```\n\nA `version_pattern` consists of three kinds of characters:\n\n- Literal text, such as `v`, `.`, and `-`, typically used as delimiters.\n- A [valid part](#parts-overview) such as `YYYY`/`WW` in the previous example.\n- Square brackets `[]` to mark an optional segment.\n\nThe following example uses all three: `vYYYY.WW[-TAG]`\n\n```\n vYYYY.WW[-TAG]\nliteral text ^ ^ ^\n```\n\n```shell\n$ bumpver test 'v2020.37-beta' 'vYYYY.WW[-TAG]'\nNew Version: v2020.41-beta\nPEP440 : 2020.41b0\n```\n\nHere we see the week number changed from 37 to 41. The test command also shows the normalized version pattern according to [PEP440][pep_440_ref]. This removes the `\"v\"` prefix and shortens the release tag from `-beta` to `b0`.\n\n[pep_440_ref]: https://www.python.org/dev/peps/pep-0440/\n\nTo remove the release tag, use the option `--tag=final`.\n\n```shell\n$ bumpver test 'v2020.37-beta' 'vYYYY.WW[-TAG]' --tag=final\nNew Version: v2020.41\nPEP440 : 2020.41\n```\n\n### Using `MAJOR`/`MINOR`/`PATCH` (SemVer Parts)\n\nA CalVer `version_pattern` may not require any flags to determine which part should be incremented, so long as the date has changed.\nWith SemVer you must always specify one of `--major/--minor/--patch`.\n\n```shell\n$ bumpver test '1.2.3' 'MAJOR.MINOR.PATCH[PYTAGNUM]' --major\nNew Version: 2.0.0\n\n$ bumpver test '1.2.3' 'MAJOR.MINOR.PATCH[PYTAGNUM]' --minor\nNew Version: 1.3.0\n\n$ bumpver test '1.2.3' 'MAJOR.MINOR.PATCH[PYTAGNUM]' --patch\nNew Version: 1.2.4\n\n$ bumpver test '1.2.3' 'MAJOR.MINOR.PATCH[PYTAGNUM]' --patch --tag=beta\nNew Version: 1.2.4b0\n\n$ bumpver test '1.2.4b0' 'MAJOR.MINOR.PATCH[PYTAGNUM]' --tag-num\nNew Version: 1.2.4b1\n```\n\nThese non date based parts also make sense for a CalVer `version_pattern`, so that you can create multiple releases in the same month. It is common to include e.g. a `PATCH` part.\n\n```shell\n$ bumpver test '2020.10.0' 'YYYY.MM.PATCH' --patch\nNew Version: 2020.10.1\n```\n\nWithout this flag, we would get an error if the date is still in October.\n\n```shell\n$ date --iso\n2020-10-15\n\n$ bumpver test '2020.10.0' 'YYYY.MM.PATCH'\nERROR - Invalid arguments or pattern, version did not change.\nERROR - Version did not change: '2020.10.0'. Invalid version and/or pattern 'YYYY.MM.PATCH'.\nINFO - Perhaps try: bumpver test --patch\n```\n\nOnce the date is in November, the `PATCH` part will roll over back to zero. This happens whenever parts to the left change (in this case the year and month), just as it does if `MAJOR` or `MINOR` were incremented in SemVer.\n\n```shell\n$ bumpver test '2020.10.1' 'YYYY.MM.PATCH' --date 2020-11-01\nNew Version: 2020.11.0\n```\n\nThe rollover to zero will happen even if you use the `--patch` argument, so that your first release in a month will always have a `PATCH` set to 0 instead of 1. You can make the `PATCH` part optional with `[.PATCH]` and always supply the `--patch` flag in your build script. This will cause the part to be omitted when 0 and added when > 0.\n\n```shell\n$ bumpver test '2020.9.1' 'YYYY.MM[.PATCH]' --patch\nNew Version: 2020.10\n\n$ bumpver test '2020.10' 'YYYY.MM[.PATCH]' --patch\nNew Version: 2020.10.1\n\n$ bumpver test '2020.10.1' 'YYYY.MM[.PATCH]' --patch\nNew Version: 2020.10.2\n```\n\n\nWith CalVer, the version is based on a calendar date, so you only have to specify such flags if you've already published a release for the current date. Without such a flag, BumpVer will show the error, that the \"version did not change\".\n\n```shell\n$ bumpver test 'v2020.41-beta0' 'vYYYY.WW[-TAGNUM]'\nERROR - Invalid arguments or pattern, version did not change.\nERROR - Invalid version 'v2020.41-beta0' and/or pattern 'vYYYY.WW[-TAGNUM]'.\n```\n\nIn this case you have to change one of the parts that are not based on a calendar date.\n\n```shell\n$ bumpver test 'v2020.41-beta0' 'vYYYY.WW[-TAGNUM]' --tag-num\nNew Version: v2020.41-beta1\nPEP440 : 2020.41b1\n\n$ bumpver test 'v2020.41-beta0' 'vYYYY.WW[-TAGNUM]' --tag=final\nNew Version: v2020.41\nPEP440 : 2020.41\n```\n\nIf a pattern is not applicable to a version string, then you will get an error message.\n\n```shell\n$ bumpver test '2020.37' 'YYYY.MM' # expected to fail because 37 is not valid for part MM\nERROR - Incomplete match '2020.3' for version string '2020.37' with pattern 'YYYY.MM'/'(?P<year_y>[1-9][0-9]{3})\\.(?P<month>1[0-2]|[1-9])'\nERROR - Invalid version '2020.37' and/or pattern 'YYYY.MM'.\n```\n\nThis illustrates that each pattern is internally translated to a regular expression which must match the version string. The `--verbose` flag will show a verbose form of the regular expression, which may help to debug the discrepancy between the pattern and the version.\n\n```shell\n$ bumpver test 'v2020.37' 'YYYY.WW' --verbose # missing \"v\" prefix\nINFO - Using pattern YYYY.WW\nINFO - regex = re.compile(r\"\"\"\n (?P<year_y>[1-9][0-9]{3})\n \\.\n (?P<week_w>5[0-2]|[1-4][0-9]|[0-9])\n\"\"\", flags=re.VERBOSE)\nERROR - Invalid version string 'v2020.37' for pattern ...\n```\n\nTo fix the above, you can either remove the \"v\" prefix from the version or add it to the pattern.\n\n```shell\n$ bumpver test 'v2020.37' 'vYYYY.WW' # added \"v\" prefix\nNew Version: v2020.41\nPEP440 : 2020.41\n```\n\n\n### Auto Increment Parts: `INC0`/`INC1`/`BUILD`\n\nThese parts are incremented automatically, and do not use/require a CLI flag: `BUILD`/`INC0`/`INC1`.\n\n```shell\n$ bumpver test '2020.10.1' 'YYYY.MM.INC0'\nNew Version: 2020.10.2\n\n$ bumpver test '2020.10.2' 'YYYY.MM.INC0' --date 2020-11-01\nNew Version: 2020.11.0\n```\n\nYou can make the part optional using the `[PART]` syntax and it will be added/removed as needed.\n\n```shell\n$ bumpver test '2020.10' 'YYYY.MM[.INC0]'\nNew Version: 2020.10.1\n\n$ bumpver test '2020.10.1' 'YYYY.MM[.INC0]' --date 2020-11-01\nNew Version: 2020.11\n```\n\nYou can the `BUILD` part to [maintain lexical ordering][url_pypi_lexid] of version numbers. This means that the expression `older < newer` will always be true, whether you are dealing with integers or strings, whether you are using software that understands how to parse version numbers or not.\n\n```shell\n$ bumpver test '2020.1001' 'YYYY.BUILD'\nNew Version: 2020.1002\n\n$ bumpver test '2020.1002' 'YYYY.BUILD'\nNew Version: 2020.1003\n\n$ bumpver test '2020.1999' 'YYYY.BUILD'\nNew Version: 2020.22000\n```\n\n[url_pypi_lexid]: https://pypi.org/project/lexid/\n\n\n### Persistent Parts: `BUILD`/`TAG`/`PYTAG`\n\nThe `BUILD` and `TAG` parts will not rollover/reset. Instead they are carried forward from one version to the next.\n\n```shell\n$ bumpver test 'v2020.1051-beta' 'vYYYY.BUILD[-TAG]'\nNew Version: v2020.1052-beta\nPEP440 : 2020.1052b0\n\n$ bumpver test 'v2020.1051-beta' 'vYYYY.BUILD[-TAG]' --date 2021-01-01\nNew Version: v2021.1052-beta\nPEP440 : 2021.1052b0\n\n$ bumpver test 'v2020.1051-beta' 'vYYYY.BUILD[-TAG]' --tag=rc\nNew Version: v2020.1052-rc\nPEP440 : 2020.1052rc0\n```\n\nTo remove a release tag, mark it as final with `--tag=final`.\n\n```shell\n$ bumpver test 'v2020.1051-beta' 'vYYYY.BUILD[-TAG]' --tag=final\nNew Version: v2020.1052\nPEP440 : 2020.1052\n```\n\n\n### Explicit `--set-version`\n\nIf the various automatic version incrementing methods don't work for you, you can explicitly do `--set-version=<version>`.\n\n```diff\n$ bumpver update --dry --set-version=\"v2020.1060\"\nINFO - Old Version: v2020.1051-beta\nINFO - New Version: v2020.1060\n--- setup.py\n+++ setup.py\n@@ -63,7 +63,7 @@\n name=\"mymodule\",\n- version=\"2020.1051b0\",\n+ version=\"2020.1060\",\n description=description,\n\n--- src/mymodule/__init__.py\n+++ src/mymodule/__init__.py\n@@ -3,3 +3,3 @@\n\n-__version__ = \"v2020.1051-beta\"\n+__version__ = \"v2020.1060\"\n```\n\n<!--\n\n#### Add git hash to version string\n\nIf you want to build a package straight from your git repository,\nwithout making a release first, you can explictly add git hash to\nthe version number using ``GITHASH`` version part.\n\nLet's say your ``pyproject.toml`` looks like this:\n\n```ini\n[bumpver]\n...\nversion_pattern = \"YYYY.BUILD[-TAG][GITHASH]\"\n...\n```\n\nThen, to update all configured files, you need to execute this command:\n\n```shell\n$ bumpver update --no-commit --no-tag --set-version=\"v202202.1085.8+ged2c3aaf\"\n```\n\nThis will modify your source tree, but won't commit or tag\nanything, so you can build your packages with that version\nnumber. Then, remember to reset local changes after (by typing\n``git reset --hard``) as standard bumpver behaviour with such\nversion number makes not much sense.\n\n-->\n\n\n### Searching for Patterns with `grep`\n\nYou can use `bumpver grep` to test and debug entries for your configuration.\n\n```shell\n$ bumpver grep \\\n\t'__version__ = \"YYYY.MM[-TAGNUM]\"' \\\n\tsrc/module/__init__.py\n\n 3:\n 4: __version__ = \"2020.9-beta1\"\n 5:\n```\n\nWhen searching your project files for version strings, there are some limitations to keep in mind:\n\n 1. A version string cannot span multiple lines.\n 2. Brackets `[]` can be escaped with backslash: `\\[\\]`.\n 3. There is no way to escape a valid part (so you cannot match the literal text `YYYY`).\n\nNote that everything in the pattern is treated as literal text, except for a valid part (in all caps).\n\n```\n __version__ = \"YYYY.MM[-TAGNUM]\"\nliteral text ^^^^^^^^^^^^^^^ ^ ^ ^\n```\n\nWhen you write your configuration, you can avoid repeating your version pattern in every search pattern, by using these placeholders\n\n- `{version}`\n- `{pep440_version}`\n\nApplied to the above example, you can instead write this:\n\n```shell\n$ bumpver grep \\\n --version-pattern \"YYYY.MM[-TAGNUM]\" \\\n '__version__ = \"{version}\"' \\\n src/module/__init__.py\n\n 3:\n 4: __version__ = \"2020.9-beta1\"\n 5:\n```\n\nThe corresponding configuration would look like this.\n\n```ini\n[bumpver]\ncurrent_version = \"2020.9-beta1\"\nversion_pattern = \"YYYY.MM[-TAGNUM]\"\n...\n\n[bumpver:file_patterns]\nsrc/module/__init__.py\n __version__ = \"{version}\"\n...\n```\n\nIf you use a version pattern that is not in the PEP440 normalized form (such as the one above), you can nonetheless match version strings in your project files which *are* in the [PEP440 normalized form][url_pep_440]. To do this, you can use the placeholder `{pep440_version}` instead of the `{version}` placeholder.\n\n```shell\n$ bumpver grep --version-pattern \"YYYY.MM[-TAGNUM]\" 'version=\"{pep440_version}\"' setup.py\nsetup.py\n 65: url=\"https://github.com/org/project\",\n 66: version=\"2020.9b1\",\n 67: description=description,\n```\n\nThe placeholder `{version}` matches `2020.9-beta1`, while the placeholder `{pep440_version}` matches `2020.9b1` (excluding the \"v\" prefix, the \"-\" separator and with a short form release tag \"b1\" instead of \"beta1\"). These two placeholders make it possible to mostly use your preferred format for version strings, but use a PEP440 compliant/normalized version string where appropriate.\n\n[url_pep_440]: https://www.python.org/dev/peps/pep-0440/\n\nAs a ~~neat trick~~ further illustration of how the search and replace works, you might wish to keep the year of your copyright headers up to date.\n\n```shell\n$ bumpver grep 'Copyright (c) 2018-YYYY' src/mymodule/*.py | head\nsrc/mymodule/__init__.py\n 3:\n 4: # Copyright (c) 2018-2020 Vandelay Industries - All rights reserved.\n 5:\n\nsrc/mymodule/config.py\n 3:\n 4: # Copyright (c) 2018-2020 Vandelay Industries - All rights reserved.\n 5:\n```\n\nThe corresponding configuration for this pattern would look like this.\n\n```ini\n[bumpver:file_patterns]\n...\nsrc/mymodule/*.py\n Copyright (c) 2018-YYYY Vandelay Industries - All rights reserved.\n```\n\nNote that there must be a match for every entry in `file_patterns`. If there is no match, `bumpver` will show an error. This ensures that a pattern is not skipped when your project changes. In this case the side effect is to make sure that every file has a copyright header.\n\n```shell\n$ bumpver update --dry\nERROR - No match for pattern 'Copyright (c) 2018-YYYY Vandelay Industries - All rights reserved.'\nERROR -\n# https://regex101.com/?flavor=python&flags=gmx®ex=Copyright%5B%20%5D%5C%28c%5C%29%0A%5B%20%5D2018%5C-%0A%28%3FP%3Cyear_y%3E%5B1-9%5D%5B0-9%5D%7B3%7D%29%0A%5B%20%5DVandelay%5B%20%5DIndustries%5B%20%5D%5C-%5B%20%5DAll%5B%20%5Drights%5B%20%5Dreserved%5C.\nregex = re.compile(r\"\"\"\n Copyright[ ]\\(c\\)\n [ ]2018\\-\n (?P<year_y>[1-9][0-9]{3})\n [ ]Vandelay[ ]Industries[ ]\\-[ ]All[ ]rights[ ]reserved\\.\n\"\"\", flags=re.VERBOSE)\nERROR - No patterns matched for file 'src/mymodule/utils.py'\n```\n\n\n## Reference\n\n### Command Line\n\n<!-- BEGIN bumpver --help -->\n\n```\n$ bumpver --help\nUsage: bumpver [OPTIONS] COMMAND [ARGS]...\n\n Automatically update version strings in plaintext files.\n\nOptions:\n --version Show the version and exit.\n -v, --verbose Control log level. -vv for debug level.\n -h, --help Show this message and exit.\n\nCommands:\n grep Search file(s) for a version pattern.\n init Initialize [bumpver] configuration.\n show Show current version of your project.\n test Increment a version number for demo purposes.\n update Update project files with the incremented version string.\n```\n\n<!-- END bumpver --help -->\n\n<!-- BEGIN bumpver update --help -->\n\n```\n$ bumpver update --help\nUsage: bumpver update [OPTIONS]\n\n Update project files with the incremented version string.\n\nOptions:\n -d, --dry Display diff of changes, don't rewrite\n files.\n -f, --fetch / -n, --no-fetch Sync tags from remote origin.\n -v, --verbose Control log level. -vv for debug level.\n --allow-dirty Commit even when working directory is has\n uncomitted changes. (WARNING: The commit\n will still be aborted if there are\n uncomitted to files with version strings.\n --ignore-vcs-tag Ignore VCS tag invariant and update version\n anyway.\n --set-version <VERSION> Set version explicitly.\n --date <ISODATE> Set explicit date in format YYYY-0M-0D (e.g.\n 2023-07-10).\n --pin-date Leave date components unchanged.\n --pin-increments Leave the auto-increments INC0 and INC1\n unchanged.\n --tag-num Increment release tag number (rc1, rc2,\n rc3..).\n -t, --tag <NAME> Override release tag of current_version.\n Valid options are: alpha, beta, dev, rc,\n post, final.\n -p, --patch Increment PATCH component.\n -m, --minor Increment MINOR component.\n --major Increment MAJOR component.\n -c, --commit-message <TMPL> Set commit message template.\n --tag-message <TMPL> Set tag message template.\n --commit / --no-commit Create a commit with all updated files.\n --tag-commit / --no-tag-commit Tag the newly created commit.\n --push / --no-push Push to the default remote.\n --tag-scope [default|global|branch]\n Tag scope for the current version.\n --pre-commit-hook <PATH> Custom script that runs before the commit\n step\n --post-commit-hook <PATH> Custom script that runs after the commit\n step is completed\n -h, --help Show this message and exit.\n```\n\n<!-- END bumpver update --help -->\n\nTo help with shell script automation, you can use `bumpver show --environ`.\n\n```shell\n$ bumpver show -n --environ\nYEAR_Y=2020\nYEAR_G=\n...\nTAG=final\n...\n\n$ eval $(bumpver show -n --environ)\n$ echo $TAG\nfinal\n```\n\n\n### Part Overview\n\n> Where possible, these patterns match the conventions from [CalVer.org][url_calver_org_scheme].\n\n[url_calver_org_scheme]: https://calver.org/#scheme\n\n| part | range / example(s) | info |\n|------------|----------------------------|---------------------------------------------|\n| `MAJOR` | 0..9, 10..99, 100.. | `bumpver update --major` |\n| `MINOR` | 0..9, 10..99, 100.. | `bumpver update --minor` |\n| `PATCH` | 0..9, 10..99, 100.. | `bumpver update --patch` |\n| `TAG` | dev, alpha, beta, rc, post | `--tag=<tag>` |\n| `PYTAG` | a, b, rc, post | `--tag=<tag>` |\n| `NUM` | 0, 1, 2... | `-r/--tag-num` |\n| `YYYY` | 2019, 2020... | Full year, based on `strftime('%Y')` |\n| `YY` | 18, 19..99, 0, 1 | Short year, based on `int(strftime('%y'))` |\n| `MM` | 9, 10, 11, 12 | Month, based on `int(strftime('%m'))` |\n| `DD` | 1, 2, 3..31 | Day, based on `int(strftime('%d'))` |\n| `BUILD` | 1001, 1002 .. 1999, 22000 | build number (maintains lexical order) |\n| `INC0` | 0, 1, 2... | 0-based auto incrementing number |\n| `INC1` | 1, 2... | 1-based auto incrementing number |\n| `PYTAGNUM` | a0, a1, rc0, ... | `PYTAG` + `NUM` (no white-space in between) |\n\n\nThe following are also available, but you should review the [Normalization Caveats](#normalization-caveats) before you decide to use them.\n\n\n| part | range / example(s) | comment |\n| ------ | ------------------- | -------------------------------------------- |\n| `Q` | 1, 2, 3, 4 | Quarter |\n| `0Y` | 18, 19..99, 00, 01 | Short Year `strftime('%y')`(zero-padded) |\n| `0M` | 09, 10, 11, 12 | Month `strftime('%m')` (zero-padded) |\n| `0D` | 01, 02, 03..31 | Day `strftime('%d')` (zero-padded) |\n| `JJJ` | 1,2,3..366 | Day of year `int(strftime('%j'))` |\n| `00J` | 001, 002..366 | Day of year `strftime('%j')` (zero-padded) |\n| `WW` | 0, 1, 2..52 | Week number\u00b9 `int(strftime('%W'))` |\n| `0W` | 00, 01, 02..52 | Week number\u00b9 `strftime('%W')` (zero-padded) |\n| `UU` | 0, 1, 2..52 | Week number\u00b2 `int(strftime('%U'))` |\n| `0U` | 00, 01, 02..52 | Week number\u00b2 `strftime('%U')` (zero-padded) |\n| `VV` | 1, 2..53 | Week number\u00b9\u00b3 `int(strftime('%V'))` |\n| `0V` | 01, 02..53 | Week number\u00b9\u00b3 `strftime('%V')` (zero-padded) |\n| `GGGG` | 2019, 2020... | `strftime(\"%G\")` ISO 8601 week-based year |\n| `GG` | 19, 20...99, 0, 1 | Short ISO 8601 week-based year |\n| `0G` | 19, 20...99, 00, 01 | Zero-padded ISO 8601 week-based year |\n\n- \u00b9 Monday is the first day of the week.\n- \u00b2 Sunday is the first day of the week.\n- \u00b3 ISO 8601 week. Week 1 contains Jan 4th.\n\n\n### Normalization Caveats\n\nPackage managers and installation tools will parse your version numbers. When doing so, your version number may go through a normalization process and may not be exactly as you specified. In the case of Python, the packaging tools (such as pip, twine, [setuptools][setuptools_ref]) follow [PEP440 normalization rules][pep_440_normalzation_ref].\n\nAccording to these rules (among other things):\n\n- Any non-numerical prefix (such as `v`) is removed\n- Leading zeros in delimited parts are truncated `XX.08` -> `XX.8`\n- Tags are converted to a short form (`-alpha` -> `a0`)\n\nFor example:\n\n- Pattern: `vYY.0M.0D[-TAG]`\n- Version: `v20.08.02-beta`\n- PEP440 : `20.8.2b0`\n\nI am not aware of any technical reason to use a normalized representation everywhere in your project. However, if you choose a pattern which is always in a normalized form, it will help to avoid confusion. For example, it may not be obvious at a glance, that `v20.08.02-beta` is the same as `20.8.2b0` .\n\nA further consideration for the choice of your `version_pattern` is that it may be processed by tools that *do not* interpret it as a version number, but treat it just like any other string. It may also be confusing to your users if they a list of version numbers, sorted lexicographically by some tool (e.g. from `git tags`) and versions are not listed in order of their release:\n\n```\n$ git tag\n18.6b4\n18.9b0\n19.10b0\n19.3b0\n20.8b0\n20.8b1\n```\n\nIf you wish to avoid this, you should use a pattern which maintains lexicographical ordering.\n\n[setuptools_ref]: https://setuptools.readthedocs.io/en/latest/setuptools.html#specifying-your-project-s-version\n\n[pep_440_normalzation_ref]: https://www.python.org/dev/peps/pep-0440/#id31\n\n\n### Pattern Examples\n\n<!-- BEGIN pattern_examples -->\n\n| pattern | examples | PEP440 | lexico. |\n|---------------------------------|-----------------------------------|--------|---------|\n| `MAJOR.MINOR.PATCH[PYTAGNUM]` | `0.13.10 0.16.10` | yes | no |\n| `MAJOR.MINOR[.PATCH[PYTAGNUM]]` | `0.11.15 0.16.18` | yes | no |\n| `YYYY.BUILD[PYTAGNUM]` | `2020.1031 2020.1406` | yes | yes |\n| `YYYY.BUILD[-TAG]` | `2021.1393-beta 2022.1279` | no | yes |\n| `YYYY.INC0[PYTAGNUM]` | `2020.4b0 2020.16` | yes | no |\n| `YYYY0M.PATCH[-TAG]` | `202210.10 202211.13-beta` | no | no\u00b9 |\n| `YYYY0M.BUILD[-TAG]` | `202005.1269-beta 202206.1056` | no | yes |\n| `YYYY.0M` | `2020.01 2021.04` | no | yes |\n| `YYYY.MM` | `2020.2 2022.2` | yes | no |\n| `YYYY.WW` | `2020.33 2020.39` | yes | no |\n| `YYYY.MM.PATCH[PYTAGNUM]` | `2022.3.1b0 2022.11.15b0` | yes | no |\n| `YYYY.0M.PATCH[PYTAGNUM]` | `2020.03.2 2022.02.4` | no | no\u00b9 |\n| `YYYY.MM.INC0` | `2020.7.10 2021.7.7` | yes | no |\n| `YYYY.MM.DD` | `2020.8.9 2020.8.20` | yes | no |\n| `YYYY.0M.0D` | `2020.11.02 2022.05.03` | no | yes |\n| `YY.0M.PATCH` | `20.05.12 22.03.5` | no | no\u00b2 |\n\n<!-- END pattern_examples -->\n\n- \u00b9 If `PATCH > 9`\n- \u00b2 For the year 2100, the part `YY` will produce 0\n\n\n### Week Numbering\n\nWeek numbering is a bit special, as it depends on your definition of \"week\":\n\n- First day of the week is either Monday or Sunday.\n- Range either from 0-52 or 1-53.\n- At the beginning/end of the year, you either have partial weeks or a week that spans multiple years.\n\nIf you use `VV`/`0V`, be aware that you cannot also use `YYYY`.\nInstead use `GGGG`. This is to avoid an edge case where your version\nnumber would run backwards if it was created around New Year.\n\n\n<!-- BEGIN weeknum_example -->\n\n```\n YYYY WW UU GGGG VV\n2020-12-26 (Sat): 2020 51 51 2020 52\n2020-12-27 (Sun): 2020 51 52 2020 52\n2020-12-28 (Mon): 2020 52 52 2020 53\n2020-12-29 (Tue): 2020 52 52 2020 53\n2020-12-30 (Wed): 2020 52 52 2020 53\n2020-12-31 (Thu): 2020 52 52 2020 53\n2021-01-01 (Fri): 2021 00 00 2020 53\n2021-01-02 (Sat): 2021 00 00 2020 53\n2021-01-03 (Sun): 2021 00 01 2020 53\n2021-01-04 (Mon): 2021 01 01 2021 01\n```\n\n<!-- END weeknum_example -->\n\n\n## Configuration\n\n### Configuration Setup\n\nThe create an initial configuration for project with `bumpver init`.\n\n```shell\n$ pip install bumpver\n...\nInstalling collected packages: click toml lexid bumpver\nSuccessfully installed bumpver-2024.1130\n\n$ cd myproject\n~/myproject/\n\n$ bumpver init --dry\nExiting because of '-d/--dry'. Would have written to bumpver.toml:\n\n [bumpver]\n current_version = \"2020.1001a0\"\n version_pattern = \"YYYY.BUILD[PYTAGNUM]\"\n commit_message = \"bump version to {new_version}\"\n tag_message = \"{new_version}\"\n tag_scope = \"default\"\n pre_commit_hook = \"\"\n post_commit_hook = \"\"\n commit = true\n tag = true\n push = true\n\n [bumpver.file_patterns]\n \"README.md\" = [\n \"{version}\",\n \"{pep440_version}\",\n ]\n \"bumpver.toml\" = [\n 'current_version = \"{version}\"',\n ]\n```\n\nIf you already have configuration file in your project (such as `setup.cfg` or `pyproject.toml`), then `bumpver init` will update that file instead.\n\n```\n~/myproject\n$ bumpver init\nUpdated pyproject.toml\n```\n\nYour `pyproject.toml` may now look something like this:\n\n```ini\n[bumpver]\ncurrent_version = \"2019.1001-alpha\"\nversion_pattern = \"YYYY.BUILD[-TAG]\"\ncommit_message = \"bump version to {new_version}\"\ntag_message = \"{new_version}\"\ntag_scope = \"default\"\npre_commit_hook = \"\"\npost_commit_hook = \"\"\ncommit = true\ntag = true\npush = true\n\n[bumpver.file_patterns]\n\"pyproject.toml\" = [\n 'current_version = \"{version}\"',\n]\n\"setup.py\" = [\n 'version=\"{pep440_version}\",',\n]\n\"README.md\" = [\n '{version}',\n '{pep440_version}',\n]\n```\n\n\n### Debugging Configuration\n\nFor the entries in `[bumpver:file_patterns]` you can expect two failure modes:\n\n- False negative: A pattern *will not* match a version number in the associated file *which it should* match.\n- False positive: A pattern *will* match something it *should not match* (less likely).\n\nMost obviously you will see such cases when you first attempt to use `bumpver update`:\n\n```shell\n$ bumpver update --dry --no-fetch\nINFO - Old Version: 2020.1001-alpha\nINFO - New Version: 2020.1002-alpha\nERROR - No match for pattern 'version=\"YYYY.BUILD[PYTAGNUM]\",'\nERROR -\n# https://regex101.com/?flavor=python&flags=gmx®ex=version%3D%5C%22%0A%28%3FP%3Cyear_y%3E%5B1-9%5D%5B0-9%5D%7B3%7D%29%0A%5C.%0A%28%3FP%3Cbid%3E%5B1-9%5D%5B0-9%5D%2A%29%0A%28%3F%3A%0A%20%20%20%20%28%3FP%3Cpytag%3Epost%7Crc%7Ca%7Cb%29%0A%20%20%20%20%28%3FP%3Cnum%3E%5B0-9%5D%2B%29%0A%29%3F%0A%5C%22%2C\nregex = re.compile(r\"\"\"\n version=\\\"\n (?P<year_y>[1-9][0-9]{3})\n \\.\n (?P<bid>[1-9][0-9]*)\n (?:\n (?P<pytag>post|rc|a|b)\n (?P<num>[0-9]+)\n )?\n \\\",\n\"\"\", flags=re.VERBOSE)\nERROR - No patterns matched for file 'setup.py'\n```\n\nThe internally used regular expression is also shown, which you can use to debug the issue, for example on [regex101.com](https://regex101.com/r/ajQDTz/2).\n\nTo debug such issues, you can simplify your pattern and see if you can find a match with `bumpver grep` .\n\n```shell\n$ bumpver grep 'YYYY.BUILD[PYTAGNUM]' setup.py\n 45: name='myproject',\n 46: version='2019.1001b0',\n 47: license='MIT',\n\n```\n\nHere we can see that the pattern for setup.py should be changed to used single quotes instead of doublequotes.\n\nAs with `bumpver update`, if your pattern is not found, `bumpver grep` will show an error message with the regular expression it uses, to help you debug the issue.\n\n```shell\n$ bumpver grep 'YYYY.BUILD[PYTAGNUM]' setup.py\nERROR - Pattern not found: 'YYYY.BUILD[PYTAGNUM]'\n# https://regex101.com/...\n```\n\nAn example of a more complex pattern is one where you want to keep a version badge in your README up to date.\n\n```shell\n$ bumpver grep 'shields.io/badge/CalVer-YYYY.BUILD[--TAG]-blue' README.md\n 61:\n 62: [img_version]: https://img.shields.io/badge/CalVer-2020.1001--beta-blue\n 63: [url_version]: https://pypi.org/org/package/\n```\n\n\n## Bump It Up\n\n\n### Version State\n\nThe `current_version` is considered global state and must be stored somewhere. Typically this might be in a `VERSION` file, or some other file which is part of the repository. This creates the risk that parallel branches can have different states. If the `current_version` were defined only by files in the local checkout, the same version might be generated on different systems for different commits.\n\nTo avoid this issue, `bumpver` treats Git/Mercurial tags as a second source, depending on the `tag_scope` option, for the most recent version and attempts to change this state in the most atomic way possible. This is why some actions of the `bumpver` command can take a few seconds, as it is synchronizing with the remote repository to get the most recent versions and to push any new version tags as soon as possible.\n\n\n### The Current Version\n\nThe current version depends on the configured `tag_scope` and is either\n\n| `tag_scope =` |\t`current_version =` |\n|---------------|-----------------------------------------------------|\n| `default` |\t`max(config.current_version, max(global_vcs_tags))` |\n| `global` | `max(global_vcs_tags)` |\n| `branch` | `max(branch_vcs_tags)` |\n\n- Before any tags have been created `bumpver` will always default to the value of `current_version` in `bumpver.toml` / `setup.cfg` / `pyproject.toml`.\n- Only Git/Mercurial tags which matches the `version_pattern` from your config will be considered and sorted using [`pkg_resources.parse_version`][url_setuptools_pkg_resources].\n\n[url_setuptools_pkg_resources]: https://setuptools.readthedocs.io/en/latest/pkg_resources.html#parsing-utilities\n\nAs part of doing `bumpver update` and `bumpver show`, your local tags are updated using `git fetch --tags`/`hg pull`.\n\n```shell\n$ bumpver show -vv\n2020-10-18T20:20:58.062 DEBUG bumpver.cli - Logging configured.\n2020-10-18T20:20:58.065 DEBUG bumpver.config - Config Parsed: Config(\n ...\n2020-10-18T20:20:58.067 DEBUG bumpver.vcs - vcs found: git\n2020-10-18T20:20:58.067 INFO bumpver.vcs - fetching tags from remote (to turn off use: -n / --no-fetch)\n2020-10-18T20:20:58.068 DEBUG bumpver.vcs - git fetch\n2020-10-18T20:21:00.886 DEBUG bumpver.vcs - git tag --list\n2020-10-18T20:21:00.890 INFO bumpver.cli - Latest version from git tag: 2020.1019\nCurrent Version: 2020.1019\n```\n\nHere we see that:\n\n- Git had a newer version than we had locally (`2020.1019` vs `2020.1018`).\n- It took 2 seconds to fetch the tags from the remote repository.\n\nThe approach of fetching tags before the version is bumped/incremented, helps to reduce the risk that the newest tag is not known locally. This means that it less likely for the same version to be generated by different systems for different commits. This would result in an ambiguous version tag, which may not be the end of the world, but is better to avoid. Typically this might happen if you have a build system where multiple builds are triggered at the same time.\n\nFor a small project (with only one maintainer and no automated packaging) this is a non-issue and you can always use `-n/--no-fetch` to skip fetching the tags.\n\n\n### Dry Mode\n\nOnce you have a valid configuration, you can use `bumpver update --dry` to see the changes it would make (and leave your project files untouched).\n\n```diff\n$ bumpver update --dry --no-fetch\nINFO - Old Version: 2019.1001-beta\nINFO - New Version: 2019.1002-beta\n--- README.md\n+++ README.md\n@@ -11,7 +11,7 @@\n\n [![Supported Python Versions][pyversions_img]][pyversions_ref]\n-[![Version 2019.1001-beta][version_img]][version_ref]\n+[![Version 2019.1002-beta][version_img]][version_ref]\n [![PyPI Releases][pypi_img]][pypi_ref]\n\n--- src/mymodule_v1/__init__.py\n+++ src/mymodule_v1/__init__.py\n@@ -1,1 +1,1 @@\n-__version__ = \"2019.1001-beta\"\n+__version__ = \"2019.1002-beta\"\n\n--- src/mymodule_v2/__init__.py\n+++ src/mymodule_v2/__init__.py\n@@ -1,1 +1,1 @@\n-__version__ = \"2019.1001-beta\"\n+__version__ = \"2019.1002-beta\"\n\n--- setup.py\n+++ setup.py\n@@ -44,7 +44,7 @@\n name=\"myproject\",\n- version=\"2019.1001b0\",\n+ version=\"2019.1002b0\",\n license=\"MIT\",\n```\n\n\n### VCS Parameters (git/mercurial)\n\nThe individual steps performed by `bumpver update`:\n\n 1. *Fetch* VCS tags from origin.\n 2. Get most recent version.\n 3. Generate the updated version string.\n 4. Check that you have no local changes that are uncommitted.\n 5. Replace version strings in all files configured in `file_patterns`.\n 6. Run pre-commit hook.\n 7. *Commit* the updated files.\n 8. Run post-commit hook.\n 9. *Tag* the new commit.\n10. *Push* the new commit and tag.\n\nThe configuration for these steps can be done with the following parameters:\n\n| Parameter | Type | Description |\n|--------------------|----------|--------------------------------------------|\n| `tag_scope` | string | Scope for the `current_version` in step 2. |\n| `commit_message` | string\u00b9 | Template for commit message in step 6. |\n| `tag_message` | string\u00b9 | Template for tag message in step 9. |\n| `pre_commit_hook` | string\u00b2 | Path to the pre-commit script. |\n| `commit` | boolean | Create a commit with all updated files. |\n| `post_commit_hook` | string\u00b2 | Path to the post-commit script. |\n| `tag` | boolean\u00b2 | Tag the newly created commit. |\n| `push` | boolean\u00b2 | Push to the default remote. |\n\n- \u00b9 Available template placeholders: `{new_version}`, `{old_version}`, `{new_version_pep440}`, `{old_version_pep440}`\n- \u00b2 Requires `commit = True`\n\nAn example configuration might look like this:\n\n```ini\n[bumpver]\n...\ncommit_message = \"bump version to {new_version}\"\ntag_message = \"{new_version}\"\ntag_scope = \"default\"\npre_commit_hook = \"scripts/run_checks.sh\"\npost_commit_hook = \"scripts/update_changelog.sh\"\ncommit = True\ntag = True\npush = True\n```\n\nIf everything looks OK, you can do `bumpver update`.\n\n```shell\n$ bumpver update --verbose\nINFO - fetching tags from remote (to turn off use: -n / --no-fetch)\nINFO - Old Version: 2020.1005\nINFO - New Version: 2020.1006\nINFO - Run pre-commit hook: scripts/run_checks.sh\nINFO - \t...\nINFO - git commit --message 'bump version to 2020.1006'\nINFO - Run post-commit hook: scripts/update_changelog.sh\nINFO - \t...\nINFO - git tag --annotate 2020.1006 --message 2020.1006\nINFO - git push origin --follow-tags 2020.1006 HEAD\n```\n\nYou can also override the config values by passing these command line flags to `bumpver update`:\n\n| Flag | Override config |\n|-------------------|-------------------------------------------------|\n| `--commit` | `commit = True` |\n| `--no-commit` | `commit = False`, `tag = False`, `push = False` |\n| `--tag-commit` | `tag = True` |\n| `--no-tag-commit` | `tag = False` |\n| `--push` | `push = True` |\n| `--no-push` | `push = False` |\n\n\n### Custom Commit Message\n\nIn addition to the `commit_message` configuration, you can also override the string used as the the commit message template with the `-c/--commit-message=<TMPL>` parameter:\n\n```shell\n$ bumpver update --tag final --commit-message 'bump version {old_version} -> {new_version} [ci-publish]' --verbose\nINFO - Old Version: 2021.1005b0\nINFO - New Version: 2021.1006\nINFO - git commit --message 'bump version 2020.1005b0 -> 2021.1006 [ci-publish]'\nINFO - git tag --annotate 2020.1006 --message '2020.1006'\nINFO - git push origin --follow-tags 2020.1006 HEAD\n```\n\nAs this is a manual operation (rather than a long lived configuration option), you can use the placeholders `OLD` and `NEW` for convenience, instead of the more verbose `{old_version}` and `{new_version}`.\n\n```shell\n$ bumpver update -f -t final -c '[final-version] OLD -> NEW'\n...\nINFO - Old Version: 1.2.0b2\nINFO - New Version: 1.2.0\nINFO - git commit --message '[final-version] 1.2.0b2 -> 1.2.0'\n...\n```\n\n\n### Custom Tag Message\n\nSimilarly to `--commit-message` you can provide a tag message template by using the `--tag-message=<TMPL>` parameter or the `tag_message` configuration:\n\n```shell\n$ bumpver update -f -t final --tag-message 'release NEW'\nINFO - Old Version: 1.2.0b2\nINFO - New Version: 1.2.0\n...\nINFO - git tag --annotate 1.2.0 --message 'release 1.2.0'\n...\n```\n\nYou can use the same placeholders as in the `--commit-message` template.\n\nIf an empty tag message is provided, bumpver uses a lightweight tag in Git. Otherwise, it utilizes an annotated Git tag. You can read more about Git tagging [here](https://git-scm.com/book/en/v2/Git-Basics-Tagging).\n\n```shell\n$ bumpver update -f -t final --tag-message ''\nINFO - Old Version: 1.2.0b2\nINFO - New Version: 1.2.0\n...\nINFO - git tag 1.2.0\n...\n```\n\n\n### Pre/Post-Commit Hooks\n\n`Bumpver` allows you to run custom scripts *before* and *after* the commit step using the `--pre-commit-hook=<PATH>` and `--post-commit-hook=<PATH>` parameter, respectively their configuration counterparts `pre_commit_hook` and `post_commit_hook`. Both options require `commit=True` to be set and the `<PATH>` must be either absolute or relative to the working dir.\n\nIf a script fails (exits with a `return_code!=0`) `bumpver` aborts and all subsequent steps won't be executed, e.g. *commit*, *tag* and *push*.\n\nFor your convenience there are two environment variables available which can be used in the scripts: `BUMPVER_OLD_VERSION` and `BUMPVER_NEW_VERSION`.\n\nExample:\n```python\n#!/usr/bin/env python\n# File path: scripts/print_new_version.py\nfrom os import environ\nprint(\"The new version is \" + environ.get('BUMPVER_NEW_VERSION', ''))\n```\n\n```\n$ bumpver update --post-commit-hook scripts/print_new_version.py\nINFO - fetching tags from remote (to turn off use: -n / --no-fetch)\nINFO - Old Version: 2023.1001-alpha\nINFO - New Version: 2023.1002-alpha\nINFO - git commit --message 'bump version 2023.1001-alpha -> 2023.1002-alpha'\nINFO - Run post-commit hook: scripts/print_new_version.py\nINFO - \tThe new version is 2023.1002-alpha\nINFO - git tag --annotate 2023.1002-alpha --message '2023.1002-alpha'\nINFO - git push origin --follow-tags 2023.1002-alpha HEAD\n```\n\nMake sure your script is executable, otherwise you might be greeted with:\n```\n$ bumpver update --post-commit-hook scripts/print_new_version.py\n...\nINFO - Run post-commit hook: scripts/print_new_version.py\nERROR - \t[Errno 13] Permission denied: 'scripts/print_new_version.py'\nERROR - Script exited with an error. Stopping\n```\n\n\n## Contributors\n\n| Name | role | since | until |\n|-------------------------------------|-------------------|---------|-------|\n| Manuel Barkhau (mbarkhau@gmail.com) | author/maintainer | 2018-09 | - |\n\n\n# Changelog for https://github.com/mbarkhau/bumpver\n\n## BumpVer 2024.1130\n\nThis update adds the vendored module `setuptools_v65_version.py` from `setuptools==v65.7.0`.\nThis was the last version with support for `LegacyVersion`.\n\n- Fix [#242][gh_i242]: Fix incorrect parsing of versions with tags.\n- Fix [#156][gh_i156]: Remove runtime dependency on setuptools and looseversion.\n\n[gh_i242]: https://github.com/mbarkhau/bumpver/issues/242\n[gh_i156]: https://github.com/mbarkhau/bumpver/issues/156\n\nThank you [Andrew Mitchell](https://github.com/MitchellAcoustics) and [Tzu-Ting](https://github.com/tzing) for your issue reports.\n\n\n## BumpVer 2023.1129\n\n- Fix [#224][gh_i224]: Add `--environ` so it emits `0` values. Depricate `-e/--env`.\n- Add [#223][gh_pr223]: Add support for `.bumpver.toml`\n\n[gh_i224]: https://github.com/mbarkhau/bumpver/issues/224\n[gh_pr223]: https://github.com/mbarkhau/bumpver/pull/223\n\nThank you [Adrianne](https://github.com/elfgirl) for this issue report.\nThank you [Xavier Francisco](https://github.com/XF-FW) for your contribution.\n\n\n## BumpVer 2023.1127\n\n- Add [#222][gh_pr222]: Add part HEXHASH.\n\n[gh_pr222]: https://github.com/mbarkhau/bumpver/pull/222\n\nThank you [Atwam](https://github.com/atwam) for your contribution.\n\n\n## BumpVer 2023.1126\n\n- Add [#214][gh_pr214]: Support for pre/post commit hooks.\n- Add [#219][gh_pr219]: Fix pathlib issues on Windows.\n- Fix [#201][gh_i201]: Better error message for SemVer corner case.\n- Update [#215][gh_i215]: Better error message for greedy pattern matching.\n- Update [#216][gh_i216]: Use .toml format in REAMDE examples.\n\n[gh_pr214]: https://github.com/mbarkhau/bumpver/pull/214\n[gh_pr219]: https://github.com/mbarkhau/bumpver/pull/219\n[gh_i201]: https://github.com/mbarkhau/bumpver/issues/201\n[gh_i215]: https://github.com/mbarkhau/bumpver/issues/215\n[gh_i216]: https://github.com/mbarkhau/bumpver/issues/216\n\nThank you [Sven Lohrmann](https://github.com/malnvenshorn) for your contribution.\nThank you [Maikel Punie](https://github.com/Cereal2nd) your issue report.\nThank you for your help in debugging Windows issues:\n - [S\u00f8ren Furbo](https://github.com/SRFU-NN)\n - [Michal Va\u0161ut](https://github.com/MichalVasut)\n - [Justin Cooksey](https://github.com/jscooksey)\n - [yqbear](https://github.com/yqbear)\n\n\n## BumpVer 2023.1125\n\n- Add [#188][gh_i188]: Add `--tag-scope=<SCOPE>` to support separate versioning for branches.\n- Add [#185][gh_i185]: Add `--tag-message=<TMPL>` parameter and `tag_message` configuration option.\n- Fix [#209][gh_i209]: Make `--no-tag-commit` ommit `--follow-tags`.\n\n[gh_i188]: https://github.com/mbarkhau/bumpver/issues/188\n[gh_i185]: https://github.com/mbarkhau/bumpver/issues/185\n[gh_i209]: https://github.com/mbarkhau/bumpver/issues/209\n\nThank you [Sven Lohrmann](https://github.com/malnvenshorn) for your contributions.\nThank you [tardis4500](https://github.com/tardis4500) for the issue report.\n\n\n## BumpVer 2023.1124\n\n- Fix [#208][gh_i208]: Fix handling of versions with PEP440 epoch.\n\n[gh_i208]: https://github.com/mbarkhau/bumpver/issues/208\n\nThank you [Wen Kokke](https://github.com/wenkokke) for the issue report.\n\n\n## BumpVer 2023.1122\n\n- Fix [#207][gh_i207]: Add --ignore-vcs-tag to support bumping older versions\n\n[gh_i207]: https://github.com/mbarkhau/bumpver/issues/207\n\nThank you [Jusong Yu](https://github.com/unkcpz) for your contribution.\n\n\n## BumpVer 2023.1121\n\n- Fix [#200][gh_i200]: Fix compatability with packaging 23.0.\n- Fix [#203][gh_i203]: Add dev to the list of valid release tags\n\n[gh_i200]: https://github.com/mbarkhau/bumpver/issues/200\n[gh_i203]: https://github.com/mbarkhau/bumpver/issues/203\n\nThank you [Sharon Yogev](https://github.com/sharonyogev) for your contribution.\n\n\n## BumpVer 2022.1120\n\n- Fix [#196][gh_i196]: Add `--pin-increments`.\n\n[gh_i196]: https://github.com/mbarkhau/bumpver/issues/196\n\nThank you [Markus Holtermann](https://github.com/MarkusH) for\nthis contribution.\n\n\n## BumpVer 2022.1119\n\n- Fix [#190][gh_i190]: Allow multiple patterns on the same line\n\n- Fix [#182][gh_i182]: Use quotes for vcs commands\n\n[gh_i190]: https://github.com/mbarkhau/bumpver/issues/190\n[gh_i182]: https://github.com/mbarkhau/bumpver/issues/182\n\n\n## BumpVer 2022.1118\n\n- Fix [#181][gh_i181]: Enable use of ``^$`` charachters to restrict\n matching to beginning and end of line.\n- Add ``GITHASH`` to ``version_pattern`` (@mpasternak)\n\n[gh_i181]: https://github.com/mbarkhau/bumpver/issues/181\n\n\n## BumpVer 2022.1116\n\n - Fix: [incorrect version comparison when updating from vcs tag][gh_i174].\n\n When comparing the updated version to the latest vcs tag,\n an insufficient string comparison was used instead of\n comparing the parsed versions.\n\n[gh_i174]: https://github.com/mbarkhau/bumpver/issues/174\n\nThank you to Timo Ludwig @timoludwig for this contribution.\n\n\n## BumpVer 2022.1115\n\n - Fix: [use default date values][gh_i172].\n\n When parsing the current version, if it doesn't specify anyt\n date part, (such as is the case for e.g. SemVer), then use the\n current date to populate default parts.\n\n This enables updating YYYY patterns in copyright headers even\n for projects that don't use a CalVer pattern.\n\n Thank you [Benjamin Depardon (@bdepardo)][gh_bdepardo] for\n finding and reporting this issue.\n\n[gh_i172]: https://github.com/mbarkhau/bumpver/issues/172\n[gh_bdepardo]: https://github.com/bdepardo\n\n\n## BumpVer 2021.1114\n\n - Add: [flags to override vcs options][gh_i168] for `bumpver update`\n\n[gh_i168]: https://github.com/mbarkhau/bumpver/issues/168\n\nThank you to Timo Ludwig @timoludwig for this contribution.\n\n\n## BumpVer 2021.1113\n\n - Add: [`--commit-message` argument][gh_i162] for `bumpver update`\n\n[gh_i162]: https://github.com/mbarkhau/bumpver/issues/162\n\n\n## BumpVer 2021.1112\n\n - Fix: Build from source on windows.\n\n\n## BumpVer 2021.1110\n\n - Fix [github#157][gh_i157]: Improve error messages.\n - Fix [github#158][gh_i158]: Clarify `PYTAGNUM` \"part\"\n\n[gh_i157]: https://github.com/mbarkhau/bumpver/issues/157\n[gh_i158]: https://github.com/mbarkhau/bumpver/issues/158\n\nThank you to Julien Palard @JulienPalard for testing and feedback.\n\n\n## BumpVer 2021.1109\n\n - Add `-e/--env` option to support shell script automation.\n - Fix [github#151][gh_i151]: invalid increment of `TAGNUM` when `TAG=final` is set.\n\n[gh_i151]: https://github.com/mbarkhau/bumpver/issues/151\n\nThank you to Dave Wapstra @dwapstra for your contributions.\n\n\n## BumpVer 2020.1108\n\n- Don't match empty patterns (possibly causing a whole file to be rewritten if braces `[]` are not escaped).\n\n\n## BumpVer 2020.1107\n\n- Non-Beta release (no significant code changes).\n\n## BumpVer 2020.1105-beta\n\n- Fix [gitlab#15][gitlab_i15]: Fix config parsing corner case.\n- Fix [gitlab#16][gitlab_i16]: Fix rollover handling for tag/pytag.\n\n[gitlab_i15]: https://gitlab.com/mbarkhau/pycalver/-/issues/15\n[gitlab_i16]: https://gitlab.com/mbarkhau/pycalver/-/issues/16\n\n\n## BumpVer 2020.1104-beta\n\n- Fix [gitlab#13][gitlab_i13]: Add `--set-version=<VERSION>` to explicitly set version.\n- Fix [gitlab#14][gitlab_i14]: Parse `tool.bumpver` when using pyproject.toml as per PEP 518.\n\n[gitlab_i13]: https://gitlab.com/mbarkhau/pycalver/-/issues/13\n[gitlab_i14]: https://gitlab.com/mbarkhau/pycalver/-/issues/14\n\n\n## BumpVer 2020.1100-beta\n\nRename package and module from PyCalVer to BumpVer. This name change is due to confusion that this project is either Python specific, or only suitible for CalVer versioning schemes, neither of which is the case.\n\nThis release includes a new syntax for patterns.\n\n```\nversion_pattern = \"vYYYY0M.BUILD[-RELEASE]\" # new style\nversion_pattern = \"v{year}{month}{build}{release}\" # old style\n\nversion_pattern = \"MAJOR.MINOR.PATCH\" # new style semver\nversion_pattern = \"{MAJOR}.{MINOR}.{PATCH}\" # old style semver\n```\n\nThe main reasons for this switch were:\n- To enable optional parts using braces `[PART]`.\n- To align the syntax with the conventions used on CalVer.org\n\nThe previous syntax will continue to be supported, but all documentation has been updated to primarily reference new style patterns.\n\n- Switch main repo from gitlab to github.\n- New [gitlab#7][gitlab_i7]: New style pattern syntax.\n - Better support for week numbers.\n - Better support for optional parts.\n - New: `BUILD` part now starts at `1000` instead of `0001` to avoid truncation of leading zeros.\n - New: Add `INC0` (0-based) and `INC1` (1-based) parts that do auto increment and rollover.\n - New: `MAJOR`/`MINOR`/`PATCH`/`INC` will roll over when a date part changes to their left.\n- New [gitlab#2][gitlab_i2]: Added `grep` sub-command to help with debugging of patterns.\n- New [gitlab#10][gitlab_i10]: `--pin-date` to keep date parts unchanged, and only increment non-date parts.\n- New: Added `--date=<iso-date>` parameter to set explicit date (instead of current date).\n- New: Added `--release-num` to increment the `alphaN`/`betaN`/`a0`/`b0`/etc. release number\n- New: Added better error messages to debug regular expressions.\n- New [gitlab#9][gitlab_i9]: Make commit message configurable.\n- Fix [gitlab#12][gitlab_i12]: Error with sorting non-lexical version tags (e.g. SemVer).\n- Fix [gitlab#11][gitlab_i11]: Show regexp when `--verbose` is used.\n- Fix [gitlab#8][gitlab_i8]: `bumpver update` will now also push HEAD (previously only the tag itself was pushed).\n- Fix: Disallow `--release=dev`. The semantics of a `dev` releases are different than for other release tags and further development would be required to support them correctly.\n- Fix: Entries in `file_patterns` were ignored if there were multiple entries for the same file.\n\nThis release no longer includes the `pycalver.lexid` module, which has been moved into its own package: [pypi.org/project/lexid/](https://pypi.org/project/lexid/).\n\nMany thanks to contributors of this release: @LucidOne, @khanguslee, @chaudum\n\n[gitlab_i7]:https://gitlab.com/mbarkhau/pycalver/-/issues/7\n[gitlab_i2]: https://gitlab.com/mbarkhau/pycalver/-/issues/2\n[gitlab_i10]: https://gitlab.com/mbarkhau/pycalver/-/issues/10\n[gitlab_i9]: https://gitlab.com/mbarkhau/pycalver/-/issues/9\n[gitlab_i12]: https://gitlab.com/mbarkhau/pycalver/-/issues/12\n[gitlab_i11]: https://gitlab.com/mbarkhau/pycalver/-/issues/11\n[gitlab_i8]: https://gitlab.com/mbarkhau/pycalver/-/issues/8\n\n\n## PyCalVer v202010.1042\n\n- Add deprication warning to README.md\n\n\n## PyCalVer v201907.0036\n\n- Fix: Don't use git/hg command if `commit=False` is configured (thanks @valentin87)\n\n\n## PyCalVer v201907.0035\n\n- Fix [gitlab#6][gitlab_i6]: Add parts `{month_short}`, `{dom_short}`, `{doy_short}`.\n- Fix [gitlab#5][gitlab_i5]: Better warning when using bump with SemVer (one of --major/--minor/--patch is required)\n- Fix [gitlab#4][gitlab_i4]: Make {release} part optional, so that versions generated by --release=final are parsed.\n\n[gitlab_i6]: https://gitlab.com/mbarkhau/pycalver/-/issues/6\n[gitlab_i5]: https://gitlab.com/mbarkhau/pycalver/-/issues/5\n[gitlab_i4]: https://gitlab.com/mbarkhau/pycalver/-/issues/4\n\n\n## PyCalVer v201903.0030\n\n- Fix: Use pattern from config instead of hard-coded {pycalver} pattern.\n- Fix: Better error messages for git/hg issues.\n- Add: Implicit default pattern for config file.\n\n\n## PyCalVer v201903.0028\n\n- Fix: Add warnings when configured files are not under version control.\n- Add: Colored output for bump --dry\n\n\n## PyCalVer v201902.0027\n\n- Fix: Allow --release=post\n- Fix: Better error reporting for bad patterns\n- Fix: Regex escaping issue with \"?\"\n\n\n## PyCalVer v201902.0024\n\n- Added: Support for globs in file patterns.\n- Fixed: Better error reporting for invalid config.\n\n\n## PyCalVer v201902.0020\n\n- Added: Support for many more custom version patterns.\n\n\n## PyCalVer v201812.0018\n\n- Fixed: Better handling of pattern replacements with \"-final\" releases.\n\n\n## PyCalVer v201812.0017\n\n- Fixed [github#2]. `pycalver init` was broken.\n- Fixed pattern escaping issues.\n- Added lots more tests for cli.\n- Cleaned up documentation.\n\n[gihlab_i2]: https://github.com/mbarkhau/pycalver/-/issues/2\n\n\n## PyCalVer v201812.0011-beta\n\n- Add version tags using git/hg.\n- Use git/hg tags as SSOT for most recent version.\n- Start using https://gitlab.com/mbarkhau/bootstrapit\n- Move to https://gitlab.com/mbarkhau/pycalver\n\n\n## PyCalVer v201809.0001-alpha\n\n- Initial release\n",
"bugtrack_url": null,
"license": "MIT",
"summary": "Bump version numbers in project files.",
"version": "2024.1130",
"project_urls": {
"Homepage": "https://github.com/mbarkhau/bumpver"
},
"split_keywords": [
"version",
"bumpver",
"calver",
"semver",
"versioning",
"bumpversion",
"pep440"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "093457d038ae30374976ce4ec57db9dea95bf55d1b5543b35e77aa9ce3543198",
"md5": "bb864ca6f5315a56737c62254aa86579",
"sha256": "8e54220aefe7db25148622f45959f7beb6b8513af0b0429b38b9072566665a49"
},
"downloads": -1,
"filename": "bumpver-2024.1130-py2.py3-none-any.whl",
"has_sig": false,
"md5_digest": "bb864ca6f5315a56737c62254aa86579",
"packagetype": "bdist_wheel",
"python_version": "py2.py3",
"requires_python": ">=2.7",
"size": 65273,
"upload_time": "2024-11-10T20:51:50",
"upload_time_iso_8601": "2024-11-10T20:51:50.383571Z",
"url": "https://files.pythonhosted.org/packages/09/34/57d038ae30374976ce4ec57db9dea95bf55d1b5543b35e77aa9ce3543198/bumpver-2024.1130-py2.py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "bba9becf78cc86211bd2287114c4f990a3bed450816696f14810cc59d7815bb5",
"md5": "3a739f4b442b2177461d5babc59bb9be",
"sha256": "74f7ebc294b2240f346e99748cc6f238e57b050999d7428db75d76baf2bf1437"
},
"downloads": -1,
"filename": "bumpver-2024.1130.tar.gz",
"has_sig": false,
"md5_digest": "3a739f4b442b2177461d5babc59bb9be",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=2.7",
"size": 115102,
"upload_time": "2024-11-10T20:51:53",
"upload_time_iso_8601": "2024-11-10T20:51:53.072571Z",
"url": "https://files.pythonhosted.org/packages/bb/a9/becf78cc86211bd2287114c4f990a3bed450816696f14810cc59d7815bb5/bumpver-2024.1130.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-11-10 20:51:53",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "mbarkhau",
"github_project": "bumpver",
"travis_ci": false,
"coveralls": false,
"github_actions": true,
"lcname": "bumpver"
}
JSON
