Always assumes repo is tagged using SemVer

[yajo]

See this session:

❯ git init .

❯ touch a

❯ git add -A

❯ git commit -amwip
[master (commit-raíz) dfbff1f] wip
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 a

❯ git tag v1

❯ dunamai from git --style pep440
Pattern '(?x)                                                (?# ignore whitespace)
    ^v(?P<base>\d+\.\d+\.\d+)                           (?# v1.2.3)
    (-?((?P<stage>[a-zA-Z]+)\.?(?P<revision>\d+)?))?    (?# b0)
    (\+(?P<tagged_metadata>.+))?$                       (?# +linux)' did not match any tags from ['v1']

It seems that even when I add --style pep440 to the command, dunamai only tries to find tags formatted with semver, because it's using this regexp:

https://github.com/mtkennerly/dunamai/blob/14a9891217a0c09da3745f1403a9ea3c54310a85/dunamai/__init__.py#L26-L31

With that regexp for example, these tags would fail:

• 1
• v1
• v1.0
• 1.2.3
• 0.1.0.1
• 1.2.3.alpha1.post4.dev3

So I think that it should:

1. prefix v be optional
2. add a specific regex for each versioning system

As a workaround, there's the possibility to pass a custom pattern if running from python:

https://github.com/mtkennerly/dunamai/blob/14a9891217a0c09da3745f1403a9ea3c54310a85/dunamai/__init__.py#L851-L857

[yajo]

I found this, that should help to know what makes a string parseable into pep440: https://github.com/pypa/packaging/blob/d59efa2141210447ae21c4d48813d720e0d1dbfd/packaging/version.py#L225-L254

[mtkennerly]

Hi! Sorry for the late response, and thanks for pointing this out. I'll definitely relax ^v(?P<base>\d+\.\d+\.\d+) to ^v(?P<base>\d+(\.\d+)*), since that was an oversight. The v prefix was a conscious decision, though, to avoid false positives from things like ticket ID-based tags, so I would consider that a backwards-incompatible change. I think the pattern should be general enough so that it doesn't need different defaults for different versioning systems, but I would be open to adding extra defaults if there's a clear need.

As a workaround, there's the possibility to pass a custom pattern if running from python:

For reference, this is also available from the command line as --pattern.

[mtkennerly]

This is now fixed in 1.6.0.