Don't normalize or escape versions

[dimbleby]

Per python-poetry/poetry#6476

• normalize_version() is only ever used as an over-elaborate way of calling Version.to_string()
• escape_version() is actually counter-productive

I've aggressively removed the functions altogether, so would need to merge python-poetry/poetry#6476 before this one (so that poetry no longer uses them).

It would be possible to leave them around unused for a bit, I favour cleaning such things up.

[dimbleby]

(don't understand why the downstream tests didn't fail, this MR surely removes things that are still used downstream)

[radoering]

It would be possible to leave them around unused for a bit, I favour cleaning such things up.

I'd prefer a deprecation warning as in

poetry-core/src/poetry/core/version/pep440/version.py

Lines 234 to 240 in 37cee90

	warnings.warn(
	"Calling next_prerelease() on a stable release is deprecated for its"
	" ambiguity. Use next_major(), next_minor(), etc. together with"
	" first_prerelease()",
	DeprecationWarning,
	stacklevel=2,
	)

When removing these functions the next core release will break poetry 1.2.0 unless we bump the major version of core. We could do this, but I don't think there is consensus among maintainers to release one major version after the other.

[dimbleby]

I'm going to not do any deprecating for a bit in the hope that y'all reach a consensus that I like better...

If for some reason you decide that merging this is urgent, feel free to reintroduce deprecated versions of the functions.

[dimbleby]

When removing these functions the next core release will break poetry 1.2.0 unless we bump the major version of core

I just noticed that this is not true, because poetry 1.2.0 pins to the exact version 1.1.0 of poetry-core: https://github.com/python-poetry/poetry/blob/85993df4fa7b67dbfe573cce7b2a397846b9c320/pyproject.toml#L47

which in some ways doesn't make a lot of difference - I'm in favour of a major version bump here anyway. But does mean that it would be possible to make breaking changes here and not signal that in the version number if for some reason that was deemed desirable.

[radoering]

I was just surprised to find a fix version in pyproject.toml. 😅

I agree a major bump would be more appropriate if we remove something although I still think deprecation warnings don't hurt and would allow faster progress...

[dimbleby]

I still think deprecation warnings don't hurt and would allow faster progress...

maybe so, but I don't expect ever to need this fix myself so I'm content to be stubborn about it!

If anyone does turn up who actually cares about the fix in here - eg epoch users per python-poetry/poetry#6466 - then they are welcome to take this and rework it so that escape_version and normalize_version are only deprecated.

[radoering]

FYI: Since it's companion has been merged, I'll probably add the deprecation warning myself later.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information