Metadata-Version: 2.1
Name: bumpit
Version: 0.1.0
Summary: A small command line tool to bump tracked versions in your repository.
Home-page: https://github.com/mobiusbyte/bumpit
Author: Jill San Luis
Author-email: jill@mobiusbyte.com
License: MIT
Project-URL: Code, https://github.com/mobiusbyte/bumpit
Project-URL: Issue tracker, https://github.com/mobiusbyte/bumpit/issues
Platform: UNKNOWN
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.7
Requires-Python: >=3.7
Description-Content-Type: text/markdown
Requires-Dist: click
Requires-Dist: pyyaml

# bumpit
A small command line tool to bump tracked versions in your repository.

It is designed to integrate well with your CI/CD pipeline. Simply install and run `bumpit` as part of your pipeline. Let the robots do the boring work!

# Installation
You can download and install `bumpit` from PyPI by running:

```
pip install bumpit
```

# Usages

There are two ways to use `bumpit`
1. through the command line, or
2. through your python code


## Through CLI
At a high level, you need to
1. setup the configuration file `.bumpconfig.yaml` in your target folder.
2. run `bumpit` or use in the code

### Usage
```shell
Usage: bumpit [OPTIONS]

Options:
  -d, --dry-run      Run the tool in dry run mode
  -c, --config TEXT  Configuration settings
  --help             Show this message and exit.
```

## Inside your program
Just do `from bumpit.core.bumpit import run` in your code.

Check out the [bumpit cli code](https://github.com/mobiusbyte/bumpit/blob/master/bumpit/console/cli.py#L29-L32) for concrete example.


## Configuration
`bumpit` relies heavily on a configuration file to capture all runtime context of `bumpit`. This config file is named `.bumpconfig.yaml` by default. You can override this using the `--config` option in the command line.

The config file looks like:

```yaml
current_version: "0.0.1"
strategy: "semver-patch"
tag: True
tag_format: "{version}"
auto_remote_push: True  # or False
tracked_files:
- setup.py
```

where:
* `current_version` - the current version of your files. It needs to be wrapped in quotes to force parsing to be string (e.g. avoid calver current_version to be parsed as float)
* `strategy` - supported values `semver-major`, `semver-minor`, `semver-patch`, `calver`
* `tag` - bool value to instruct the tool to tag the repository after the version update
* `tag_format` - format of the tag. Some people prefer to add prefix to their tag versions (e.g. `release/1.0.1`). As long as the `{version}` is present, then it is a valid `tag_format`
* `auto_remote_push` - bool flag that guards whether to push commit and/or tag changes to remote repository. It should never be wrapped in quotes so that it will be properly parsed as a bool
* `tracked_files` - a list of relative filenames to update version to. If the current_version is not found, the tool simply skips this file

# Examples
Check out the following repositories for examples:
* [CalVer](https://github.com/mobiusbyte/bumpit-calver-fixtures) example
* [SemVer](https://github.com/mobiusbyte/bumpit-semver-fixtures) example
* [bumpit](https://github.com/mobiusbyte/bumpit/blob/master/.bumpit.yaml) - yep! `bumpit` uses `bumpit`.

# Version Strategies
The tool currently supports the following versioning strategies
* [Semantic Version](https://semver.org/)
* [Calendar Version](https://calver.org/)

## Semantic Version
`bumpit` implements a very basic semver scheme. It validates the right format using the [proposed format](https://semver.org/#is-there-a-suggested-regular-expression-regex-to-check-a-semver-string).

Notice that semantic version has optional `meta` tokens after the usual `major.minor.patch` tokens. When `meta` token is present and `bumpit` runs, `bumpit` naively updates the `major.minor.patch` version based on the strategy and leaves the `meta` token as is. If this is not your expected behaviour, please help me understand how it should be handled. You can create an issue and perhaps a PR of your proposed solution.

## Calendar Version
`bumpit` implements a very basic calver scheme. It assumes that the version follows the format `YYYYmm.variant` where
* `YYYY` - year
* `mm` - month zero padded
* `variant` - incrementing integer to distinguish different version for the same month

When the month rolls over to the next, `YYYYmm` will be the new month, and `variant` resets to `1`.

The format is quite concrete. This was sufficient enough for my use case. However, if you feel that this is too simplistic, please feel free to create an issue and perhaps a PR of your proposed solution.


# Development
## Contribution
Code and documentation improvements are all welcome. You can also file bug reports or feature suggestions.

The feature set is meant to handle different versioning strategies. Currently, the strategies I know are applied in the wild are implemented, but it is by no means complete!

## Publishing
To publish `bumpit`, run the following

```shell
git checkout master
git pull
bumpit
python setup.py bdist_wheel sdist
twine upload dist/*
```


# License
`bumpit` is released under the [MIT License](https://opensource.org/licenses/MIT).



