# bumpsemver
[](https://pypi.org/project/bumpsemver/)
[](https://pypi.org/project/bumpsemver/)
[](https://pypi.org/project/bumpsemver/)
[](https://codecov.io/gh/zhaow-de/bumpsemver)
[](https://github.com/zhaow-de/bumpsemver/actions)
Current version: **v2.3.0**
## Table of contents
<!--TOC-->
- [Overview](#overview)
- [Installation](#installation)
- [Usage](#usage)
- [Command Line Interface](#command-line-interface)
- [Configuration file](#configuration-file)
- [General config section](#general-config-section)
- [File-specific config sections](#file-specific-config-sections)
- [File types supported in the file-specific config section](#file-types-supported-in-the-file-specific-config-section)
- [Plain text file](#plain-text-file)
- [JSON file](#json-file)
- [YAML file](#yaml-file)
- [TOML file](#toml-file)
<!--TOC-->
## Overview
A utility to simplify the version bumping for git repos.
This application is a rework of the famous `bumpversion` tool. The
[original repo](https://github.com/peritus/bumpversion) seems like abandoned. Several fundamental changes are
introduced, which make the fork-and-extend approach infeasible:
1. dropped Python 2 support
2. boosted the test coverage to 95%+
3. dropped many irrelevant features to reduce complexity. (e.g. customized version component support)
4. introduced JSON support to make it work for package-lock.json
5. introduced YAML support to make it work for Ansible playbooks
6. introduced TOML support to make it work for pyproject.toml
7. narrowed the versioning scheme to semver-only
## Installation
```bash
pip install --upgrade bumpsemver
```
## Usage
This application supports both the CLI mode and config file mode.
Options on the command line take precedence over those from the config file, which take precedence over those from the
defaults.
## Command Line Interface
```bash
bumpsemver [options] part
```
##### **`options`** _**(optional)**_
Most of the configuration values described below can also be given as an option on the command-line.
Additionally, the following options are available:
`--dry-run`
Don't touch any files, just pretend. Best used with `--verbose`.
`--allow-dirty`
Normally, bumpsemver will abort if the working directory is dirty to avoid releasing not versioned files
and/or overwriting unsaved changes. Use this option to override this check.
`--verbose`
Print useful information about the action details.
`-h, --help`
Print help and exit.
##### **`part`** _**(required)**_
The part of the version to increase. As we support semver only, the valid values include: `major`, `minor`, and `patch`.
For example, bumping from 0.5.1 to 0.6.0:
```bash
bumpsemver --current-version 0.5.1 minor
```
## Configuration file
`bumpsemver` looks up configuration file `.bumpsemver.cfg` at the current directory.
The config file uses [`ini` syntax](https://en.wikipedia.org/wiki/INI_file).
It consists of one general section `[bumpsemver]` and zero or more `[bumpsemver:type(suffix):filename]` file sections.
Example `.bumpsemver.cfg`:
```ini
[bumpsemver]
current_version = 0.2.9
commit = True
tag = True
[bumpsemver:plaintext:README.md]
search = Version: **{current_version}**
replace = Version: **{new_version}**
[bumpsemver:plaintext(header):home.md]
search = Version: **{current_version}**
replace = Version: **{new_version}**
[bumpsemver:plaintext(footer 1):home.md]
search = Current version: {current_version}
replace = Current version: {new_version}
[bumpsemver:json:example.json]
jsonpath = foobar.items[1].version
[bumpsemver:yaml:example.yml]
yamlpath = dummy.version
[bumpsemver:toml:example.toml]
tomlpath = project.version
```
### General config section
General configuration is grouped in a `[bumpsemver]` section of `.bumpsemver.cfg`.
It has the following properties:
##### **`current_version =`** _**(required).**_ _**default**_: none
The current version of the software package before bumping.
Also available as CLI argument `--current-version` (e.g. `bumpsemver --current-version 0.5.1 patch`)
##### **`tag = (True | False)`** _**(optional).**_ _**default**_: `False`
Whether to create a git tag, that is the new version, prefixed with the character "`v`".
Also available as CLI argument `--tag` or `--no-tag`.
##### **`sign_tags = (True | False)`** _**(optional).**_ _**default**_: `False`
Whether to sign tags.
Also available as CLI argument `--sign-tags` or `--no-sign-tags`.
##### **`tag_name =`** _**(optional).**_ _**default**_: `v{new_version}`
The name of the tag that will be created. Only valid when `tag = True`.
It can be a template using the [Python Format String Syntax](https://docs.python.org/3/library/string.html#format-string-syntax).
Available in the template context are `current_version` and `new_version` as well as `current_[part]` and `new_[part]`
(e.g. '`current_major`' or '`new_patch`'). You can also use the variables `now` or `utcnow` to get a current timestamp.
Both accept datetime formatting (when used like as in `{now:%d.%m.%Y}`).
Also available as CLI argument `--tag-name`, for example: `bumpsemver --tag-name 'release-{new_version}' patch`
In addition, it is also possible to provide a tag message by using CLI `--tag-message TAG_MESSAGE`. Example usage:
`bumpsemver --tag-name 'release-{new_version}' --tag-message "Release {new_version}" patch`
If neither tag message nor sign tag is provided, we use a `lightweight` tag in git. Otherwise, we utilize an `annotated`
git tag. Read more about Git tagging [here](https://git-scm.com/book/en/v2/Git-Basics-Tagging).
##### **`commit = (True | False)`** _**(optional).**_ _**default**_: `False`
Create a commit using git when true.
Also available as CLI argument `--commit` or `--no-commit`.
##### **`message =`** _**(optional).**_ _**default**_: `build(repo): bumped version {current_version} → {new_version}`
The commit message to use when creating a commit. Only valid when using `--commit` / `commit = True`.
It can be a template using the [Python Format String Syntax](https://docs.python.org/3/library/string.html#format-string-syntax).
Available in the template context are `current_version` and `new_version` as well as `current_[part]` and `new_[part]`
(e.g. '`current_major`' or '`new_patch`'). You can also use the variables `now` or `utcnow` to get a current timestamp.
Both accept datetime formatting (when used like as in `{now:%d.%m.%Y}`).
Also available as CLI argument `--message`, for example: `bumpsemver --tag-name 'release-{new_version}' patch`
### File-specific config sections
A file-specific config section is required for each file to specify the handling of the particular file.
One config file can have zero or more file-specific config sections.
The section name looks like `[bumpsemver:type:filename]`.
It specifies the action to be done for a specific file.
We do have the use case that one file has multiple places to change, a popular example is `package-lock.json`:
```json
{
"name": "app-cli",
"version": "1.1.0",
"lockfileVersion": 3,
"requires": true,
"packages": {
"": {
"name": "app-cli",
"version": "1.1.0",
"license": "SEE LICENSE IN LICENSE"
}
}
}
```
We need two config sections for the same file in this case, but INI format does not allow duplicated section names.
To make it work, we could append a description between parens to the
`type` keyword: `[bumpsemver:plaintext(special one):…]`. It does not matter what inside the parens, just make it unique.
For the example below, the two patterns will be applied separately to the same file `README.md`:
```ini
[bumpsemver:plaintext(1):README.md]
search = current version: {current_version}
replace = current version: {new_version}
[bumpsemver:plaintext(footer):README.md]
search = **Version: {current_version}**
replace = **Version: {new_version}**
```
### File types supported in the file-specific config section
All the famous `bump*version` utilities family has a common pattern to handle the files as a plain text file.
The advantage of this approach is that in fact it makes the use scenario programming language-neutral.
Be it a package-lock.json for node.js project, or pyproject.toml for a Python application,
the `bump*version` is applicable as long as a proper regex pattern for version extraction can be defined.
However, it will bring significant side effect for complex file for example `package-lock.json`.
A typical (relatively) complex React projects contains 1000+ npm packages indirectly.
For randomly sampled 30 public projects at GitHub written in node.js/TypeScript,
the classical `bumpversion` or the renovated `bump2version` both made mistakes
for all 30 projects which changed something shouldn't be changed.
For instance, the `facebook/create-react-app` application has a large fleet of indirect
npm dependencies.
If we define the search pattern as `"version": "4.0.0"`, we will screw up the other 210 packages.
Or if we are unluckily releasing our app bumping the version from `7.16.0` to `8.0.0`,
other 132 npm packages in the version lock will be changed to `8.0.0`, which likely do not exist.
To address this issue, `bumpsemver` added the support of some popular file types
to access the particular version attribute using a deterministic locator/selector without regex.
The supported file types are:
* plaintext
* json
* yaml
* toml
`bumpsemver` will use the file extension to determine the file type and throw an error if the detected file type
mismatches with the specified one.
This behavior can be overridden by specifying the file type with a `!` suffix.
For example, `[bumpsemver:json!:config.yaml]` will treat `config.yaml` as a JSON file.
#### Plain text file
The file-specific config section looks like:
```ini
[bumpsemver:plaintext:filename]
search = Version: {current_version}
replace = Version: {new_version}
```
A deprecated syntax is also supported:
```ini
[bumpsemver:file:filename]
```
We renamed (in a backward compatible way) `file` or `plaintext` to emphasize
that the file being processed is considered as a plain text file.
You can easily destroy a JSON file by a missing a double-quote or a comma in the regex pattern.
This file type should generally only be used for the files that are not JSON, YAML, or TOML.
`README.md` is a good use case for this one.
`[bumpsemver:plaintext:...]` can have two properties:
##### **`search =`** _**default**_: `{current_version}`
Template string how to search for the string to be replaced in the file.
Useful if the remotest possibility exists that the current version number might be present multiple times in the file,
and you mean to only bump one of the occurrences.
##### **`replace =`** _**default**_: `{new_version}`
Template to create the string that will replace the current version number in the file.
Given this `requirements.txt`:
```
Django>=1.5.6,<1.6
MyProject==1.5.6
```
using the following `.bumpsemver.cfg` will ensure only the line containing `MyProject` will be changed:
```ini
[bumpsemver]
current_version = 1.5.6
[bumpsemver:plaintext:requirements.txt]
search = MyProject=={current_version}
replace = MyProject=={new_version}
```
#### JSON file
The file-specific config section looks like:
```ini
[bumpsemver:json:package.json]
jsonpath = version
```
It accepts only one property:
##### **`jsonpath =`** **(required)** _**default**_: none
Value of the parameter `jsonpath` is a [JSONPath](https://goessner.net/articles/JsonPath/) string,
it points to the exact property of the version string to be bumped.
For the typical `package.json`, using `version` or its jQuery-style alternative `$.version` is sufficient.
Otherwise, anything can be selected with JSONPath is support, so, nothing we can't do.
The underlying JSONPath processor is [jsonpath-ng](https://github.com/h2non/jsonpath-ng).
Checkout their document for some examples and hints.
The suffix is also supported for json file:
```ini
[bumpsemver:json(1):example.json]
jsonpath = version
[bumpsemver:json( same file):example.json]
jsonpath = dependencies[2].*.version
[bumpsemver:json (once again):example.json]
jsonpath = dependencies[0].*.lodash.dependencies[1].version
```
#### YAML file
Comparably, YAML is supported for the same reason that we should support native JSON, like
```ini
[bumpsemver:yaml:playbook.yml]
yamlpath = version
```
OR
```ini
[bumpsemver:yaml(1):playbook.yml]
yamlpath = *.vars.project_version
[bumpsemver:yaml( same file):playbook.yaml]
yamlpath = *.vars.version
[bumpsemver:yaml (once again):playbook.yaml]
yamlpath = *.vars.app_version
```
Please note that we use
[yamlpath](https://github.com/wwkimball/yamlpath/wiki/Segments-of-a-YAML-Path#yaml-path-standard) here.
`yamlpath` is not a popular "standard" widely adopted as `jsonpath`.
For complex scenarios, it makes sense to test the expression with [yamlpath cli](https://pypi.org/project/yamlpath/)
before putting anything in the config file.
#### TOML file
The file-specific config section looks like:
```ini
[bumpsemver:toml:pyproject.toml]
tomlpath = tool.poetry.version
```
For whatever reason toml gets its acceptance and popularity, especially in the Go, Rust, and later Python community.
Despite the unlogical fashion and religion drives, in fact we have many toml files in the wild.
For instance `pyproject.toml` is everywhere now.
We cannot even find out a "tomlpath" or similar library to read/update the properties in a toml file by giving a
string as the "path" to the property.
We rolled our own tomlpath processor, which is not a standard, but offering similar functionality as yamlpath.
Raw data
{
"_id": null,
"home_page": "https://github.com/zhaow-de/bumpsemver",
"name": "bumpsemver",
"maintainer": null,
"docs_url": null,
"requires_python": "<4,>=3.10",
"maintainer_email": null,
"keywords": "bumpsemver, semver, version, release",
"author": "Zhao Wang",
"author_email": "zhaow.km@gmail.com",
"download_url": "https://files.pythonhosted.org/packages/9a/17/efb4345f20a90d8781ee11c9e927855d26652263dbfe29ffa96f64ed6d81/bumpsemver-2.3.0.tar.gz",
"platform": null,
"description": "# bumpsemver\n\n[](https://pypi.org/project/bumpsemver/)\n[](https://pypi.org/project/bumpsemver/)\n[](https://pypi.org/project/bumpsemver/)\n[](https://codecov.io/gh/zhaow-de/bumpsemver)\n[](https://github.com/zhaow-de/bumpsemver/actions)\n\n\nCurrent version: **v2.3.0**\n\n## Table of contents\n\n<!--TOC-->\n\n- [Overview](#overview)\n- [Installation](#installation)\n- [Usage](#usage)\n- [Command Line Interface](#command-line-interface)\n- [Configuration file](#configuration-file)\n - [General config section](#general-config-section)\n - [File-specific config sections](#file-specific-config-sections)\n - [File types supported in the file-specific config section](#file-types-supported-in-the-file-specific-config-section)\n - [Plain text file](#plain-text-file)\n - [JSON file](#json-file)\n - [YAML file](#yaml-file)\n - [TOML file](#toml-file)\n\n<!--TOC-->\n\n## Overview\n\nA utility to simplify the version bumping for git repos.\n\nThis application is a rework of the famous `bumpversion` tool. The \n[original repo](https://github.com/peritus/bumpversion) seems like abandoned. Several fundamental changes are\nintroduced, which make the fork-and-extend approach infeasible:\n1. dropped Python 2 support\n2. boosted the test coverage to 95%+\n3. dropped many irrelevant features to reduce complexity. (e.g. customized version component support)\n4. introduced JSON support to make it work for package-lock.json\n5. introduced YAML support to make it work for Ansible playbooks\n6. introduced TOML support to make it work for pyproject.toml \n7. narrowed the versioning scheme to semver-only\n\n## Installation\n\n```bash\npip install --upgrade bumpsemver\n```\n\n## Usage\n\nThis application supports both the CLI mode and config file mode.\nOptions on the command line take precedence over those from the config file, which take precedence over those from the\ndefaults.\n\n## Command Line Interface\n\n```bash\nbumpsemver [options] part\n```\n \n##### **`options`** _**(optional)**_\n \nMost of the configuration values described below can also be given as an option on the command-line.\nAdditionally, the following options are available:\n\n`--dry-run`\nDon't touch any files, just pretend. Best used with `--verbose`.\n\n`--allow-dirty`\nNormally, bumpsemver will abort if the working directory is dirty to avoid releasing not versioned files\nand/or overwriting unsaved changes. Use this option to override this check.\n\n`--verbose`\nPrint useful information about the action details.\n\n`-h, --help`\nPrint help and exit.\n\n##### **`part`** _**(required)**_\n\nThe part of the version to increase. As we support semver only, the valid values include: `major`, `minor`, and `patch`.\n\nFor example, bumping from 0.5.1 to 0.6.0:\n\n```bash\nbumpsemver --current-version 0.5.1 minor\n```\n\n## Configuration file\n\n`bumpsemver` looks up configuration file `.bumpsemver.cfg` at the current directory.\nThe config file uses [`ini` syntax](https://en.wikipedia.org/wiki/INI_file).\nIt consists of one general section `[bumpsemver]` and zero or more `[bumpsemver:type(suffix):filename]` file sections. \n\nExample `.bumpsemver.cfg`:\n\n```ini\n[bumpsemver]\ncurrent_version = 0.2.9\ncommit = True\ntag = True\n\n[bumpsemver:plaintext:README.md]\nsearch = Version: **{current_version}**\nreplace = Version: **{new_version}**\n\n[bumpsemver:plaintext(header):home.md]\nsearch = Version: **{current_version}**\nreplace = Version: **{new_version}**\n\n[bumpsemver:plaintext(footer 1):home.md]\nsearch = Current version: {current_version}\nreplace = Current version: {new_version}\n\n[bumpsemver:json:example.json]\njsonpath = foobar.items[1].version\n\n[bumpsemver:yaml:example.yml]\nyamlpath = dummy.version\n\n[bumpsemver:toml:example.toml]\ntomlpath = project.version\n```\n\n### General config section\n\nGeneral configuration is grouped in a `[bumpsemver]` section of `.bumpsemver.cfg`.\nIt has the following properties:\n\n##### **`current_version =`** _**(required).**_ _**default**_: none\n\nThe current version of the software package before bumping.\n\nAlso available as CLI argument `--current-version` (e.g. `bumpsemver --current-version 0.5.1 patch`)\n\n##### **`tag = (True | False)`** _**(optional).**_ _**default**_: `False`\n\nWhether to create a git tag, that is the new version, prefixed with the character \"`v`\".\n\nAlso available as CLI argument `--tag` or `--no-tag`.\n\n##### **`sign_tags = (True | False)`** _**(optional).**_ _**default**_: `False`\n\nWhether to sign tags.\n\nAlso available as CLI argument `--sign-tags` or `--no-sign-tags`.\n\n##### **`tag_name =`** _**(optional).**_ _**default**_: `v{new_version}`\n\nThe name of the tag that will be created. Only valid when `tag = True`.\n\nIt can be a template using the [Python Format String Syntax](https://docs.python.org/3/library/string.html#format-string-syntax). \nAvailable in the template context are `current_version` and `new_version` as well as `current_[part]` and `new_[part]`\n(e.g. '`current_major`' or '`new_patch`'). You can also use the variables `now` or `utcnow` to get a current timestamp.\nBoth accept datetime formatting (when used like as in `{now:%d.%m.%Y}`).\n\nAlso available as CLI argument `--tag-name`, for example: `bumpsemver --tag-name 'release-{new_version}' patch`\n\nIn addition, it is also possible to provide a tag message by using CLI `--tag-message TAG_MESSAGE`. Example usage:\n`bumpsemver --tag-name 'release-{new_version}' --tag-message \"Release {new_version}\" patch`\n\nIf neither tag message nor sign tag is provided, we use a `lightweight` tag in git. Otherwise, we utilize an `annotated`\ngit tag. Read more about Git tagging [here](https://git-scm.com/book/en/v2/Git-Basics-Tagging).\n\n##### **`commit = (True | False)`** _**(optional).**_ _**default**_: `False`\n\nCreate a commit using git when true.\n\nAlso available as CLI argument `--commit` or `--no-commit`.\n\n##### **`message =`** _**(optional).**_ _**default**_: `build(repo): bumped version {current_version} \u2192 {new_version}`\n\nThe commit message to use when creating a commit. Only valid when using `--commit` / `commit = True`.\n\nIt can be a template using the [Python Format String Syntax](https://docs.python.org/3/library/string.html#format-string-syntax). \nAvailable in the template context are `current_version` and `new_version` as well as `current_[part]` and `new_[part]`\n(e.g. '`current_major`' or '`new_patch`'). You can also use the variables `now` or `utcnow` to get a current timestamp.\nBoth accept datetime formatting (when used like as in `{now:%d.%m.%Y}`).\n\nAlso available as CLI argument `--message`, for example: `bumpsemver --tag-name 'release-{new_version}' patch`\n\n### File-specific config sections\n\nA file-specific config section is required for each file to specify the handling of the particular file.\nOne config file can have zero or more file-specific config sections.\nThe section name looks like `[bumpsemver:type:filename]`.\nIt specifies the action to be done for a specific file.\n\nWe do have the use case that one file has multiple places to change, a popular example is `package-lock.json`:\n```json\n{\n \"name\": \"app-cli\",\n \"version\": \"1.1.0\",\n \"lockfileVersion\": 3,\n \"requires\": true,\n \"packages\": {\n \"\": {\n \"name\": \"app-cli\",\n \"version\": \"1.1.0\",\n \"license\": \"SEE LICENSE IN LICENSE\"\n }\n }\n}\n```\nWe need two config sections for the same file in this case, but INI format does not allow duplicated section names.\nTo make it work, we could append a description between parens to the\n`type` keyword: `[bumpsemver:plaintext(special one):\u2026]`. It does not matter what inside the parens, just make it unique.\nFor the example below, the two patterns will be applied separately to the same file `README.md`:\n```ini\n[bumpsemver:plaintext(1):README.md]\nsearch = current version: {current_version}\nreplace = current version: {new_version}\n\n[bumpsemver:plaintext(footer):README.md]\nsearch = **Version: {current_version}**\nreplace = **Version: {new_version}**\n```\n\n### File types supported in the file-specific config section\n\nAll the famous `bump*version` utilities family has a common pattern to handle the files as a plain text file.\nThe advantage of this approach is that in fact it makes the use scenario programming language-neutral.\nBe it a package-lock.json for node.js project, or pyproject.toml for a Python application,\nthe `bump*version` is applicable as long as a proper regex pattern for version extraction can be defined.\n\nHowever, it will bring significant side effect for complex file for example `package-lock.json`.\nA typical (relatively) complex React projects contains 1000+ npm packages indirectly.\nFor randomly sampled 30 public projects at GitHub written in node.js/TypeScript,\nthe classical `bumpversion` or the renovated `bump2version` both made mistakes\nfor all 30 projects which changed something shouldn't be changed.\n\nFor instance, the `facebook/create-react-app` application has a large fleet of indirect\nnpm dependencies.\nIf we define the search pattern as `\"version\": \"4.0.0\"`, we will screw up the other 210 packages.\nOr if we are unluckily releasing our app bumping the version from `7.16.0` to `8.0.0`,\nother 132 npm packages in the version lock will be changed to `8.0.0`, which likely do not exist.\nTo address this issue, `bumpsemver` added the support of some popular file types\nto access the particular version attribute using a deterministic locator/selector without regex.\n\nThe supported file types are:\n* plaintext\n* json\n* yaml\n* toml\n\n`bumpsemver` will use the file extension to determine the file type and throw an error if the detected file type \nmismatches with the specified one.\nThis behavior can be overridden by specifying the file type with a `!` suffix.\nFor example, `[bumpsemver:json!:config.yaml]` will treat `config.yaml` as a JSON file.\n\n#### Plain text file\n\nThe file-specific config section looks like:\n```ini\n[bumpsemver:plaintext:filename]\nsearch = Version: {current_version}\nreplace = Version: {new_version}\n```\n\nA deprecated syntax is also supported:\n```ini\n[bumpsemver:file:filename]\n```\nWe renamed (in a backward compatible way) `file` or `plaintext` to emphasize\nthat the file being processed is considered as a plain text file.\nYou can easily destroy a JSON file by a missing a double-quote or a comma in the regex pattern.\n\nThis file type should generally only be used for the files that are not JSON, YAML, or TOML.\n`README.md` is a good use case for this one.\n\n`[bumpsemver:plaintext:...]` can have two properties:\n\n##### **`search =`** _**default**_: `{current_version}`\n\nTemplate string how to search for the string to be replaced in the file.\nUseful if the remotest possibility exists that the current version number might be present multiple times in the file,\nand you mean to only bump one of the occurrences.\n\n##### **`replace =`** _**default**_: `{new_version}`\n\nTemplate to create the string that will replace the current version number in the file.\n\nGiven this `requirements.txt`:\n```\n Django>=1.5.6,<1.6\n MyProject==1.5.6\n```\nusing the following `.bumpsemver.cfg` will ensure only the line containing `MyProject` will be changed:\n```ini\n[bumpsemver]\ncurrent_version = 1.5.6\n\n[bumpsemver:plaintext:requirements.txt]\nsearch = MyProject=={current_version}\nreplace = MyProject=={new_version}\n```\n\n#### JSON file\n\nThe file-specific config section looks like:\n```ini\n[bumpsemver:json:package.json]\njsonpath = version \n```\n\nIt accepts only one property:\n\n##### **`jsonpath =`** **(required)** _**default**_: none\n\nValue of the parameter `jsonpath` is a [JSONPath](https://goessner.net/articles/JsonPath/) string,\nit points to the exact property of the version string to be bumped.\nFor the typical `package.json`, using `version` or its jQuery-style alternative `$.version` is sufficient.\nOtherwise, anything can be selected with JSONPath is support, so, nothing we can't do.\nThe underlying JSONPath processor is [jsonpath-ng](https://github.com/h2non/jsonpath-ng).\nCheckout their document for some examples and hints.\n\nThe suffix is also supported for json file:\n```ini\n[bumpsemver:json(1):example.json]\njsonpath = version\n\n[bumpsemver:json( same file):example.json]\njsonpath = dependencies[2].*.version\n\n[bumpsemver:json (once again):example.json]\njsonpath = dependencies[0].*.lodash.dependencies[1].version\n```\n\n#### YAML file\n\nComparably, YAML is supported for the same reason that we should support native JSON, like\n ```ini\n[bumpsemver:yaml:playbook.yml]\nyamlpath = version \n```\nOR\n```ini\n[bumpsemver:yaml(1):playbook.yml]\nyamlpath = *.vars.project_version\n\n[bumpsemver:yaml( same file):playbook.yaml]\nyamlpath = *.vars.version\n\n[bumpsemver:yaml (once again):playbook.yaml]\nyamlpath = *.vars.app_version\n```\n\nPlease note that we use\n[yamlpath](https://github.com/wwkimball/yamlpath/wiki/Segments-of-a-YAML-Path#yaml-path-standard) here.\n`yamlpath` is not a popular \"standard\" widely adopted as `jsonpath`.\nFor complex scenarios, it makes sense to test the expression with [yamlpath cli](https://pypi.org/project/yamlpath/)\nbefore putting anything in the config file.\n\n#### TOML file\n\nThe file-specific config section looks like:\n```ini\n[bumpsemver:toml:pyproject.toml]\ntomlpath = tool.poetry.version\n```\n\nFor whatever reason toml gets its acceptance and popularity, especially in the Go, Rust, and later Python community.\nDespite the unlogical fashion and religion drives, in fact we have many toml files in the wild.\nFor instance `pyproject.toml` is everywhere now.\n\nWe cannot even find out a \"tomlpath\" or similar library to read/update the properties in a toml file by giving a\nstring as the \"path\" to the property.\nWe rolled our own tomlpath processor, which is not a standard, but offering similar functionality as yamlpath.\n",
"bugtrack_url": null,
"license": "MIT",
"summary": "Bump semver for git repos with a single command",
"version": "2.3.0",
"project_urls": {
"Homepage": "https://github.com/zhaow-de/bumpsemver",
"Repository": "https://github.com/zhaow-de/bumpsemver"
},
"split_keywords": [
"bumpsemver",
" semver",
" version",
" release"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "07070b2060347d18287530e92dc079bfff7e7f093fb4aa2c058330f1a1a196d8",
"md5": "90623596472e6c2809a1135b97baf3af",
"sha256": "7984ac308f7b829a92f4e977687f339b1e8b412b602e111cbce5d6e6422af41d"
},
"downloads": -1,
"filename": "bumpsemver-2.3.0-py3-none-any.whl",
"has_sig": false,
"md5_digest": "90623596472e6c2809a1135b97baf3af",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": "<4,>=3.10",
"size": 28993,
"upload_time": "2024-05-01T22:01:44",
"upload_time_iso_8601": "2024-05-01T22:01:44.186344Z",
"url": "https://files.pythonhosted.org/packages/07/07/0b2060347d18287530e92dc079bfff7e7f093fb4aa2c058330f1a1a196d8/bumpsemver-2.3.0-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "9a17efb4345f20a90d8781ee11c9e927855d26652263dbfe29ffa96f64ed6d81",
"md5": "7846132dd2e8330b8a50102961b28e59",
"sha256": "f4b038f71b2f21b655c895cc1a7e3a05052e4a768cc329af4f6065f77a99c50a"
},
"downloads": -1,
"filename": "bumpsemver-2.3.0.tar.gz",
"has_sig": false,
"md5_digest": "7846132dd2e8330b8a50102961b28e59",
"packagetype": "sdist",
"python_version": "source",
"requires_python": "<4,>=3.10",
"size": 27984,
"upload_time": "2024-05-01T22:01:46",
"upload_time_iso_8601": "2024-05-01T22:01:46.410160Z",
"url": "https://files.pythonhosted.org/packages/9a/17/efb4345f20a90d8781ee11c9e927855d26652263dbfe29ffa96f64ed6d81/bumpsemver-2.3.0.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-05-01 22:01:46",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "zhaow-de",
"github_project": "bumpsemver",
"travis_ci": false,
"coveralls": false,
"github_actions": true,
"requirements": [],
"lcname": "bumpsemver"
}
JSON
