[Python-Dev] New functionality in micro releases (was:Documenting branch policy)

[Raymond Hettinger]

[Just van Rossum]
>  > Apart
>  > from real bugs, I think every program that works on 2.x.y should work on
>  > 2.x.z, regardless of whether y > z or y < z.

[Fred Drake]
> Depending on just what you mean "every program that works", this could
> completely prevent these bugfix releases.  We might not be able to
> remove a core dump since it would allow code to run that was not run
> before, thereby changing the behavior of the code.

JvR did qualify it with:  "apart from real bugs".  The only question is how
"real" does it have to be.  I think all of the following should be fair game:

  * not matching documented behavior (for example: '%F" % x)
  * usability fixes
  * performance issues (strptime caching for example)
  * something that can only be crashed by an obscure case
     (Armin Rigo's itertools.izip hack)
  * leaks (the massive leak in the array module)
  * security fixes
  * enhancing the docs (chm files, examples, new docs, etc.)
  * adding capabilities to standalone Tools/scripts or IDLE
  * updates to separately maintained packages (like "email")
     so that between major releases, Python won't get terribly
     far behind the stable releases of the package.
  
I think of micro releases as being the same as service patches which are
supposed to be painless upgrades that any admin or user can load without
fear of breaking existing code. That should likely be the standard rather
than requiring that all programs work irrespective of the micro version.

If an application is affected by a bug in an earlier micro version, it
isn't terribly unreasonable to ask the users to download the service patch
which should be relatively effortless as compared with installing a new
major release.


Raymond Hettinger