Create pre instead of post versions

[ggtools]

I've been using setuptools_scm for quite a while and dunamai/poetry-dynamic-versioning are exactly what I was looking for to migrate my projects to poetry. Almost actually as there is a big difference.

Let's start with a tag for version 0.1.0. In dunamai, the version computed after n commits will be something like 0.1.0-post<n>.dev0+<git-hash>. In setuptools_scm the version will be something like 0.1.1.dev<n>+g<git-hash>.

In my workflow the commits after putting a tag are considered as the beginning of a new version more than fixes to the previous one. In a perfect world the version would be 0.2.0.dev<n>+g<git-hash> but setuptools_scm is definitely closer to my workflow than dunamai.

[mtkennerly]

Hello! This can be achieved, but currently requires some scripting on your side. You can import Dunamai as a library and write some code to serialize the version that way, or if you're using poetry-dynamic-versioning, you can use the format-jinja option (see here for an example of changing how the post/dev suffixes work).

One thing to consider is how Dunamai should determine the next version. If the latest tag is v0.1.0, there are at least 12 potential next versions: primarily v0.1.1, v0.2.0, and v1.0.0, plus combinations with the a1, b1, and rc1 suffixes. Is that configurable in setuptools_scm? From a brief look, it seems to always increment the last position and not touch a/b/rc numbers.

Now, I could definitely look into adding some facilities to streamline the custom code for cases like this. Right now, either you go through Dunamai's built-in formatting or you construct the entire version string yourself, which is a bit of a pain, so it might be nicer to provide a serialize_pep440() function that lets you specify something like serialize_pep440(base=bump(version.base, minor=True), dev=version.distance) to override the default mappings, and then poetry-dynamic-versioning could expose the same functionality through format-jinja. How does that sound?

[ggtools]

setuptools_scm is not idea as incrementing the last number is not exactly what I want but that's kind of OK. I agree that it should be configurable and will probably be a huge feature as the next version really depends on the workflow people are using and might become a hell if you want to consider branches.

I'm indeed using poetry-dyanamic-versioning so I have a look at solution you're proposing.

[mtkennerly]

This is now easier with Dunamai v1.1.0 and poetry-dynamic-versioning v0.6.0. bump_version takes an optional argument of the index to increment and defaults to the last position (-1).

Dunamai sample:

from dunamai import Version, bump_version, serialize_pep440

v = Version.from_git()
if v.distance == 0:
    out = serialize_pep440(v.base, v.stage, v.revision)
elif v.revision is not None:
    out = serialize_pep440(v.base, v.stage, v.revision + 1, dev=v.distance, metadata=["g" + v.commit])
else:
    out = serialize_pep440(bump_version(v.base, 1), v.stage, v.revision, dev=v.distance, metadata=["g" + v.commit])
print(out)

poetry-dynamic-versioning sample:

format-jinja = """
    {%- if distance == 0 -%}
        {{ serialize_pep440(base, stage, revision) }}
    {%- elif revision is not None -%}
        {{ serialize_pep440(base, stage, revision + 1, dev=distance, metadata=["g" + commit]) }}
    {%- else -%}
        {{ serialize_pep440(bump_version(base, 1), stage, revision, dev=distance, metadata=["g" + commit]) }}
    {%- endif -%}
"""

This should streamline your use case while still giving you full control over the mapping. Let me know what you think \:D

[ggtools]

Yes definitely good. There's just the None which should be in lower case in jinja but it works definitely as I wanted. Thanks