Semver compliance is broken

[szymonrychu]

According to semver 2.0 specification (mentioned in official poetry docs), there is no special requirements for pre-release suffix- namely:

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z.–.

https://semver.org/#spec-item-9

Therefore a version like:

0.2.4-1608127111-1a6ba6b

is valid and should be treated as pre-release one. In other words when semver range specified like this:

examplelib = "^0.2.4"

such pre-release should be ommited. That would suggest necessity of adding development flag to mix to also support such pre-release versions (for example the same way as helm charts do).

In my case I'm unable to send such library with exception as follows:

Building examplelib (0.2.4-1608127111-1a6ba6b)

  InvalidVersion

  Invalid version: '0.2.4-1608127111-1a6ba6b'

  at /opt/hostedtoolcache/Python/3.9.0/x64/lib/python3.9/site-packages/poetry/core/version/version.py:56 in __init__
       52│     def __init__(self, version):
       53│         # Validate the version and parse it into pieces
       54│         match = VERSION_PATTERN.match(version)
       55│         if not match:
    →  56│             raise InvalidVersion("Invalid version: '{0}'".format(version))
       57│ 
       58│         # Store the parsed out pieces of the version
       59│         self._version = _Version(
       60│             epoch=int(match.group("epoch")) if match.group("epoch") else 0,

And there is no mention of treating pre-release packages according to scheme I/semver docs describe above.

[szymonrychu]

OK- There is one mention of development flag that might potentially work like I've noted here in the config example and it's named allow-prereleases.
Unfortunately the flag itself is not documented anywhere (probably relates to this bug: python-poetry/poetry#1665)

[szab100]

Same issue here. We use semantic versioning, but the final semver is from our 'master' branch, while we have a pre-release branch called 'develop' as well. Each PRs merged into our pre-release 'develop' branch receives an auto-generated semver of '..-develop.'. So I agree, the pattern should allow anything after ... I personally would like to include this full version (incl the pre-release postfix) in the PKG-INFO, so that we will know from the logs that it's a pre-release.

$ poetry build
Building pos-wf-manager (0.1.0-develop.2)
InvalidVersion
Invalid version: '0.1.0-develop.2'

[jfaleiro]

I am seeing the same thing:

InvalidVersion
  Invalid version: '0.0.4-4-gea0e40c'
  at /usr/local/lib/python3.8/site-packages/poetry/core/version/version.py:61 in __init__

This issue is breaking setup-scmversion. We use semantic_version to validate a well-formed semantic version, while poetry just checks if a string matches a re pattern under poetry.core.version.version.VERSION_PATTERN:

def __init__(self, version):  # type: (str) -> None
    # Validate the version and parse it into pieces
    match = VERSION_PATTERN.match(version)
    if not match:
       raise InvalidVersion("Invalid version: '{0}'".format(version))

Would it be too much to ask to have the version compliance validation delegated to some library outside of poetry, or at the very least use poetry's own poetry-semver?

[marcoacierno]

Same use case I think, I want to create a version from the git hash as pre-release

  ~/projects/testrepo on   main !1 ?1 ❯ poetry version 2.0.0-dev.cd8d55f4b1b89                                                                                                                                                                                                 with marco@remotedev at  11:15:45 PM
Bumping version from 2.0.0-dev11111 to 2.0.0-dev.cd8d55f4b1b89
  ~/projects/testrepo on   main !1 ?1 ❯ poetry publish --build                                                                                                                                                                                                                 with marco@remotedev at  11:16:56 PM

  InvalidVersion

  Invalid version: '2.0.0-dev.cd8d55f4b1b89'

  at ~/.poetry/lib/poetry/_vendor/py3.9/poetry/core/version/version.py:61 in __init__
       57│     def __init__(self, version):  # type: (str) -> None
       58│         # Validate the version and parse it into pieces
       59│         match = VERSION_PATTERN.match(version)
       60│         if not match:
    →  61│             raise InvalidVersion("Invalid version: '{0}'".format(version))
       62│
       63│         # Store the parsed out pieces of the version
       64│         self._version = _Version(
       65│             epoch=int(match.group("epoch")) if match.group("epoch") else 0,

to create temporary versions of a library, but poetry doesn't consider it valid

[ypicard]

Same thing here.
On the official semver documents, they have a recommended regex to parse versions:
^(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-9]\d*)(?:-(?P<prerelease>(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P<buildmetadata>[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$.

What are the updates on this?

[reitzig]

Seems to me that poetry implements PEP 440, which disagress with SemVer.

[simonsuthers]

Is there any update on this?

Thanks

[ypicard]

Hello?

[spezold]

@simonsuthers @ypicard You might not be lucky in receiving an answer here, as the separate semver project seems abandoned, and the code now seems to be integrated into the actively maintained poetry-core (corresponding functionality can be found in poetry.core.semver). Maybe try your luck by opening a new issue there?

Disclaimer: I am part of neither project.