Pronounciation

• IPA: /bæmp/

Verb

1. simple past tense and past participle of bump

Bamp saves you precious time by bamping version in all configured files, creating commit and tag (coming this fall) with one simple command. Bamp follows SemVer when bamping versions, bringing a bit of sanity into the world of dependencies.

Easiest way to explain how to start is with examples of how to use Bamp. Imagine a developer of a fresh library called notlob who has just started and is about to release his first version. Bamp for notlob is configured with location of files to bamp and the current version to minimise the effort.

• increasing the minor part of the version.

    $ bamp minor
    New version: 0.1.0
  

• increasing the patch part of the version.

    $ bamp patch
    New version: 0.1.1
  

• increasing the major part of the version.

    $ bamp major
    New version: 1.0.0
  

• increasing the minor part of the version with git commit.

    $ bamp minor --commit
    New version: 1.1.0
  

• increasing the patch part of the version with git commit and custom message.

    $ bamp patch --commit --message "Bamping!"
  

• outputting the new version number without actually changing files.

    $ bamp patch --dry-run
  

• outputting current version only (implies --dry-run).

    $ bamp current
  

Configuration of bamp is stored in INI format. First place where bamp checks for configuration is bamp.cfg in the current directory. If bamp.cfg can't be located bamp checks for bamp section in setup.cfg.

Example bamp.cfg config file.

[bamp]
version=0.0.1
files=
    setup.py
    src/__init__.py
vcs=git
commit=True
message=Bamp version: {current_version} -> {new_version}
allow_dirty=False
tag=True
tag_name={new_version}

All the options can be passed as arguments to bamp executable. If one would like to bamp minor part in a file with custom message would do it like this.

bamp minor --version 2.15.10 --files setup.py --commit --message "Bamping!"

As a bit of extra goodness it partially supports configuration used by bumpversion software. Path files defined in bumpversion format will be honoured by bamp and updated accordingly. You may simply point bamp at the configuration file or let it seek for expected file names.

Flag indicating if bamp can create a commit in a dirty repository.

allow_dirty=False

Flag for creating a commit. If set to true bamp will use a default commit message or use one provided via -m/--message argument or taken from the config file.

commit=True

List of path files which will be bamped. It is possible to specify more than one path. bamp will check if each of the paths exists before proceeding.

files=
    setup.py
    src/__init__.py

Commit message to be used when bamping.

message=Bamp version: {current\_version} -> {new\_version}

Following variables will be substituted:

• current_version - for the version before bamping
• new_version - for the version after bamping

Flag for creating a tag. If set to true bamp will use a default tag message or use one provided via -T/--tag-name argument or taken from the config file.

tag=True

Tag name to be used when bamping.

tag_name={new\_version}

Following variables will be substituted:

• current_version - for the version before bamping
• new_version - for the version after bamping

Set version control which is used. Only git is supported at this time.

vcs=git

This allows to set the version number. This number will be seeked in files and bamped accordingly. Bamp fails if the version can not be located.

version=0.1.0

Limit how many occurrences of the version number will be updated in each file. For example, if you version=1.2.3 string is near the top of your file, but it also contains version specifiers for other requirements, such as django>=1.2.3, then the default limit of 1 will ensure that only the first occurrence is updated. If you'd prefer to update all occurrences, then set limit=0. limit may be set to any positive integer to update that many occurrences.

limit=1