[Python-ideas] module version number support for semver.org

[Terry Reedy]

On 4/15/2014 3:25 PM, Andrew Barnert wrote:
> Sent from a random iPhone
>
> On Apr 14, 2014, at 21:41, Terry Reedy
> <tjreedy at udel.edu> wrote:
>
>> As I said in response to this same post on python-list, one problem
>> with mechanical semantic interpretation of version numbers, the
>> supposed justification for the system, is that such interpretation
>> does not work as soon as one accidentally makes a release that
>> violates the semantic rules.
>
> To be fair, semver tries to deal with that. It's arguable whether it
> does so sufficiently, but at least it doesn't ignore the problem.

In my original response on python-list, I quoted parts of the semver 
faq. I should have quoted instead of summarizing my original response.

> Also, having a semantic interpretation that's almost always
> mechanically interpretable but occasionally not isn't completely
> useless.

Indeed, I said that it is quite useful, but not perfect.

A separate criticism of 'Python should officially support Semantic 
Versioning', interpreted as 'Python should use Semantic Versioning for 
its version numbers', is that a) Python already does (or at least tries 
to) with respect to micro/patch releases, but that the semver semantics 
for major/minor numbers are not practical for CPython as a bundle of 
perhaps 200 modules. But if Hees is not proposing a change in CPython 
numbering, then this is not relevant to what he did mean.

> If my project relies on 2.3.4+ but not 3.x of your project,
> and your 2.3.7 breaks backward compatibility, that's a bug in your
> project.

Agreed. But it means that one cannot use the simplistic algorithm given 
on the web page: usable = '2.3.4' <= version < '3.0.0'.

> As long as you publicize the bug and any appropriate
> workarounds and fix it (e.g., by releasing a 2.3.8), it's the same as
> any other bug (like your 2.3.7 failing to install, or crashing any
> time anyone calls the spam function).

My point was and is that one needs a special case modification to the 
usable expression:
  usable = '2.3.4' <= version < '3.0.0' and version != '2.3.7'

One semver rule is that a release cannot be modified, even to fix it, 
without modifying the version number. (This is another rule CPython 
follows.) This is a practical rule since once something is released on 
the internet, it cannot be deleted or edited everywhere, and it would be 
confusing to have different files with the same identifier. But not 
allowing edits does conflict with the usability rule.

A partial* solution would be for PyPI to maintain a set containing 
'denounced by the author' releases. CPython 3.0.* could go in such a 
set. Some releases that were replaced within a month could definitely go 
in such. Then a more generic usability expression could be
   usable = '2.3.4' <= version < '3.0.0' and version not in denounced
and similarly for other dependency calculations.

* partial because mistakes are not always noticed

-- 
Terry Jan Reedy