Allow easy generation of preversion

[gsemet]

Hello,

This is linked to !2, I would like to easily generated preversion instead of postversion.

From what I understand, post version is not supported by semver 2.0. If we are 5 commits ahead of version 1.2.3, dunamai generate:

$ dunamai from any --no-metadata --style semver
1.2.3-post.3

while Semver would require (to my understanding) a version such as 1.2.4-pre.3. This is important since some implementation might put 1.2.3-post.3 actually before 1.2.3.

Would it be possible to add an option to the command line argument to prefer .pre instead of .post.

Today I manage to have this behavior in my poetry package (V.post allowed but I prefer to stick with what PBR do, like (V+1).devX), with a jinja template:

format-jinja = """
    {%- if distance == 0 -%}
        {{ serialize_pep440(base, stage, revision) }}
    {%- elif revision is not none -%}
        {{ serialize_pep440(base, stage, revision + 1, dev=distance) }}
    {%- else -%}
        {{ serialize_pep440(bump_version(base), stage, revision, dev=distance) }}
    {%- endif -%}
"""

but this is easy to do in command line. thanks

[mtkennerly]

You're absolutely right about the SemVer sorting. It's a trade-off, but I think it's a safe default since it avoids having to make any assumptions about how base looks.

My view is that, since Dunamai as a library tries to be generic across all versioning schemes, I would rather not add extra built-in formats to Dunamai itself, but rather let higher-level tools (like poetry-dynamic-versioning) implement their own formats as a convenience. I could see potentially adding an option in poetry-dynamic-versioning for common alternative formats, like:

format-common = "pep440-incremented-prerelease"

It gets tricky, though, because of all the variation that people might still want. For example:

• Which part of base do you want to increment? Your example is a good default, but I'm sure someone would eventually want to be able to override it to go from 1.2.3 to 2.0.0.dev1.
• Do you want to add an incrementing stage/revision instead of adding a .devN suffix?
• When do you want to include the commit hash and/or dirty flag? (always, never, conditionally)

I'm not sure which variants would be the most commonly used, so I just want to be careful about deciding which ones to add as a baseline. You mentioned PBR - maybe a good place to start would be defining some formats that are equivalent to options from other tools like that one and Versioneer.

[gsemet]

For the python world, indeed there are lot of variation possible. PBR does its own choices, but other are possible indeed.

But for the semver format output, out of the box with dunamai unfortunately the output string is not good, and cannot be used directly (ex with python-node) without having to hardcode kind of templating everytime.

I would recommend to change the semver style to increment-preversion by default (since there is no other solution that is compatible with semver) and indeed do not change the pep440 style.

[mtkennerly]

After thinking about this some more, I agree that it's worth adding directly to Dunamai, since fundamentally there should be an option that follows SemVer's sort order. For backwards compatibility, I'd rather not change the default, but I'm adding a --bump option to handle this (which I'll expose in poetry-dynamic-versioning as well).

Assuming that git describe says v1.3.1-3-g28c1684, then:

options	output
--style pep440	1.3.1.post3.dev0+28c1684
--style pep440 --bump	1.3.2.dev3+28c1684
--style semver	1.3.1-post.3+28c1684
--style semver --bump	1.3.2-pre.3+28c1684
--style pvp	1.3.1-post-3-28c1684
--style pvp --bump	1.3.2-pre-3-28c1684

Additionally:

• It will increment the revision if it's set: 0.1.0a3 becomes 0.1.0a4
• If you have a stage without a revision, it sets the revision to 2: 0.1.0a becomes 0.1.0a2

[gsemet]

thanks, I think that can do the job :D

[mtkennerly]

This is available in v1.4.0+. I'm planning to do the corresponding poetry-dynamic-versioning release once I fix https://github.com/mtkennerly/poetry-dynamic-versioning/issues/30.

[mtkennerly]

@gsemet FYI, poetry-dynamic-versioning v0.11.0 now includes a corresponding bump option.