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

[Steve Holden]

[Raymond Hettinger]
> >   * not matching documented behavior (for example: '%F" % x)
>
[Guido]
> 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)!
>
Such as the socket mismatch that was fixed in (IIRC) 1.6, to loud
complaints from half the network programming world? This still bites
occasionally when old cord has to be brought forward to more recent
versions (though, of course, it isn't hard to make the necessary
changes).

[...]
> >   * 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.
>
Yup. Any potential for code breakage is going to cause somebody
somewhere a certain amount of pain. It's these edge cases that cause
most of the problems, since overall the version-to-version compatibility
picture is actually remarkably good. But people will cheerfully ignore
the 99.99% of their code that *doesn't* break, and bitch about the
little bits that do :-)

> > 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.
>
If you want something to be true sufficiently hard, anything convenient
will be seen as supporting evidence.

Raymond did, however, pinpoint the reason why I haven't yet started
using True and False.

what-*me*-conservative-ly y'rs  - steve
--
Steve Holden                                 http://www.holdenweb.com/
Python Web Programming                http://pydish.holdenweb.com/pwp/
Interview with GvR August 14, 2003       http://www.onlamp.com/python/