module version number support for semver.org

[Terry Reedy]

On 4/10/2014 6:45 PM, Jörn Hees wrote:
> what do you think about officially supporting Semantic Versioning?
> (http://semver.org  )

It is a nice fantasy.

Under "Why...?" the author, Tom Preston-Werner,  says
"A simple example will demonstrate how Semantic Versioning can make 
dependency hell a thing of the past. Consider a library called 
"Firetruck." It requires a Semantically Versioned package named 
"Ladder." At the time that Firetruck is created, Ladder is at version 
3.1.0. Since Firetruck uses some functionality that was first introduced 
in 3.1.0, you can safely specify the Ladder dependency as greater than 
or equal to 3.1.0 but less than 4.0.0. Now, when Ladder version 3.1.1 
and 3.2.0 become available, you can release them to your package 
management system and know that they will be compatible with existing 
dependent software."

Except you cannot know. Even though Firetruck works with Ladder 3.1.0, 
one *cannot* know for sure that is will work with Ladder 3.1.1, let 
alone 3.2.0.

1. Python use patch (micro, .z) numbers for bug fixes. Tom specifies 
"backwards compatible bug fixes". There ain't no such thing. Bug fixes 
break code that depends on the bug. Such dependence may be unintentional 
and not known until a supposedly safe patch release breaks the code that 
uses it.

2. Accidents, including regressions, happen. In respone to FAQ "What do 
I do if I accidentally release a backwards incompatible change as a 
minor version?" (which probably happends with every x.y.0 CPython 
release), Tom says

"As soon as you realize that you've broken the Semantic Versioning spec, 
fix the problem and release a new minor version that corrects the 
problem and restores backwards compatibility. Even under this 
circumstance, it is unacceptable to modify versioned releases. If it's 
appropriate, document the offending version and inform your users of the 
problem so that they are aware of the offending version."

This is well and good, but it invalidates the claim that one can 
reliably depend and mechanically base action on future release numbers. 
The answer to "What if I inadvertently alter the public API in a way 
that is not compliant with the version number change?" has the same problem.

This is not to say that Semver does not improve the situation when it 
can be used.

-- 
Terry Jan Reedy