Non-compliant versioning

[jaraco]

Original report by Éric Araujo (Bitbucket: Merwok, GitHub: Merwok).

---

Hi! I just noticed the backport; have you announced it somewhere?

The x.yrz scheme you’re using does not respect PEP 386.

[jaraco]

Original comment by Łukasz Langa (Bitbucket: ambv, GitHub: ambv).

---

There was no actual announcement, you're right that I should do one.

The 3.2.0r1 scheme conforms with the LooseVersion class. A perfect versioning scheme for a backport should have the following features:

• Pointing explicitly to the upstream version. Here: 3.2.0 means taken from Python 3.2.0.
• Allowing for multiple releases based on the same upstream version. Here: 3.2.0r3 is the third release based on Python 3.2.0.

Actually, the single point where the current versioning scheme fails to conform with the StrictVersion class is the usage of "r" instead of "a" or "b". Unfortunately, both of these options would suggest unstable quality of the backport which I consider unacceptable. "r" standing for "release" is neutral.

If you happen to have an idea for another versioning scheme which conforms with StrictVersion and keeps the features described above, I'm willing to change it.

[jaraco]

Original comment by Éric Araujo (Bitbucket: Merwok, GitHub: Merwok).

---

I’d suggest using things like 3.2.0.3 to mean third release based on Python 3.2.0.

[jaraco]

Original comment by Łukasz Langa (Bitbucket: ambv, GitHub: ambv).

---

What does that give us when 1.2.3.4 is still an invalid StrictVersion?

[jaraco]

Original comment by Éric Araujo (Bitbucket: Merwok, GitHub: Merwok).

---

I don’t think anybody uses StrictVersion.

[jaraco]

Original comment by Łukasz Langa (Bitbucket: ambv, GitHub: ambv).

---

Fixed in 3.5.0b1.