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

[Guido van Rossum]

>   * not matching documented behavior (for example: '%F" % x)

Depends on how you fix these.  Fixing the code may break more code
than fixing the docs (assuming the mismatch existed for a long time)!

>   * usability fixes

What are these?  Seems like a loophole the size of a large truck.

>   * 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

But every attempt should be made to fix these without changing APIs.

>   * enhancing the docs (chm files, examples, new docs, etc.)
>   * adding capabilities to standalone Tools/scripts or IDLE

Questionable, if these are installed.  Esp. now that IDLE is part of
the standard library.

>   * 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.

Again, this should be done with the utmost backwards compatibility in
mind, and even then, new features are new features, and thus may cause
the problem Jack and Just warn about.

> 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.

Right, but keep in mind that few people except hardcore Python users
are going to upgrade their Python, no matter how painless, just to run
some small piece of software they downloaded.  They'll just toss the
download as one of so many broken things, proof that free software
sucks.

--Guido van Rossum (home page: http://www.python.org/~guido/)