Add an easy way to maintain PEP 440 compatible version identifiers

[keimlink]

PEP 440 defines a new scheme for identifying versions of Python software distributions. bumpversion should offer an easy way to maintain all kinds of version identifiers supported by PEP 440.

Example

If I want to use "dev" releases to allow my users to download development releases from PyPI I have to use the following bumpversion configuration:

[bumpversion]
files = setup.py docs/conf.py
commit = True
current_version = 0.2.0.dev0
parse = 
    (?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)(?:\.dev(?P<dev>\d+))?
serialize = 
    {major}.{minor}.{patch}.dev{dev}
    {major}.{minor}.{patch}

[bumpversion:part:dev]
values = 
    0
    1
    2
    3
    4
optional_value = 4

After releasing 0.1.2 users can execute bumpversion minor and will move the version to 0.2.0.dev0 which is fine.

But to have no "dev" release at all or to stop doing "dev" releases optional_value has to be set manually to the value of the release to be skipped. So I would appreciate it if users could use an option to move from 0.2.0.dev0 to 0.2.0.

Currently I have no idea how options for this behaviour could look like.

[peritus]

At this time, there's two answers to this:

With the current version you could repeatedly execute

$> bumpversion dev

so the version would go 0.2.0.dev0 → 0.2.0.dev1 → 0.2.0.dev2 → 0.2.0.dev3 → 0.2.0. That's a handful unneccessary changes (and commits and tags) and even if you squash them afterwards, that extra work is not why I wrote bumpversion in the first place, you're right.

Best guess would probably to implement #50, then you could do

$> bumpversion dev=4

and it would go 0.2.0.dev0 → 0.2.0 directly (btw, a s/4/RELEASE/ on your config would make it more understandable).

Still trying to wrap my head around this or whether that could be solved in a more elegant way.

[peritus]

Edit: I did s/patch dev=4/dev=4/ on the last example above.

[keimlink]

50 looks like a good way to circumvent the problem easily.

[tuukkamustonen]

Could be even nicer if bumpversion detected the development build number from SCM (for example, through git describe)

[peritus]

@tuukkamustonen Could you elaborate on that ?

bumpversion uses git describe underneath to detect version numbers already, what are you missing ?

[tuukkamustonen]

Sorry, I haven't used bumpversion, just found it and I'm reading docs so I might have missed something...

To me, it seems like bumpversion relies on information committed to SCM in files (.bumpversion.cfg, setup.py). So, when I make a commit and want to build a developmental release, the build number (how many commits since the last release) is not obtained from git describe and I would need to set it in files (change it for each commit). But maybe bumpversion already does this somehow?

I'm also looking at https://pypi.python.org/pypi/setuptools-version-command. The idea there is that version identifier is interpreted solely from git describe. Does bumpversion allow the same?

Edit: Changed pre-release into developmental release

[peritus]

@tuukkamustonen I'd have to look into that, maybe bumpversion can mimick setuptools-version-command as it is today. Could you file a separate issue (just copy-pasting what you posted here will do) as a reminder ?

Closing this as duplicate of #55.

[tuukkamustonen]

@peritus Ok, opened #80.

[peritus]

It's actually a duplicate of #50, not 55.

[alanbriolat]

@keimlink: I realise this issue is closed, but I had the same problem as you and solved it slightly differently, by adding a dev part (with no special configuration) and also a release part (like bumpversion's own). Perhaps somebody will find this useful.

[bumpversion]
current_version = 0.1.0
commit = True
tag = False
parse = (?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)(\.(?P<release>[a-z]+)(?P<dev>\d+))?
serialize = 
    {major}.{minor}.{patch}.{release}{dev}
    {major}.{minor}.{patch}

[bumpversion:part:release]
optional_value = gamma
values = 
    dev
    gamma

[bumpversion:part:dev]

Using the release part removes the problem of needing to define an endpoint for dev. So, from this starting point:

• bumpversion patch: 0.1.0 -> 0.1.1.dev0
• bumpversion release: 0.1.1.dev0 -> 0.1.1
• bumpversion minor: 0.1.1 -> 0.2.0.dev0
• bumpversion dev: 0.2.0.dev0 -> 0.2.0.dev1
• bumpversion release: 0.2.0.dev1 -> 0.2.0

(I would combine tag = False in the config with using bumpversion --tag release, to prevent tagging all the non-release versions.)