Guido:
>Aahz:
>>
>> [to Thomas Wouters]
>>
>> I'm thinking one of us is confused. CVS is hosted at SourceForge,
>> right? People can download specific parts of Python from SF? And we're
>> presuming there will be a specific fork that patches are checked in to?
>> So in what way is my statement not true?
>
> Ah... Thomas clearly thought you meant the patch manager, and you
> didn't make it too clear that's not what you meant. Yes, they are of
> course all available as diffs -- and notice how I use this fact in the
> 2.0 patches lists in the 2.0 wiki, e.g. on
> http://www.python.org/cgi-bin/moinmoin/CriticalPatches.
Of course I didn't make it clear, because I have no clue what I'm
talking about. ;-) And actually, I was talking about simply
downloading complete replacements for specific Python source files.
But that seems to be irrelevent to our current path, so I'll shut up now.
>> Well, given that neither of us is arguing on the basis of actual
>> experience with Python patch releases, there's no way we can prove one
>> point of view as being better than the other. Tell you what, though:
>> take the job of Patch Czar, and I'll follow your lead. I'll just
>> reserve the right to say "I told you so". ;-)
>
> It seems I need to butt in here. :-)
>
> I like the model used by Tcl. They have releases with a 6-12 month
> release cycle, 8.0, 8.1, 8.2, 8.3, 8.4. These have serious alpha and
> beta cycles (three of each typically). Once a release is out, the
> issue occasional patch releases, e.g. 8.2.1, 8.2.2, 8.2.3; these are
> about a month apart. The latter bugfixes overlap with the early alpha
> releases of the next major release. I see no sign of beta cycles for
> the patch releases. The patch releases are *very* conservative in
> what they add -- just bugfixes, about 5-15 per bugfix release. They
> seem to add the bugfixes to the patch branch as soon as they get them,
> and they issue patch releases as soon as they can.
>
> I like this model a lot. Aahz, if you want to, you can consider this
> a BDFL proclamation -- can you add this to your PEP?
BDFL proclamation received. It'll take me a little while to rewrite
this into an internally consistent PEP. It would be helpful if you
pre-announced (to c.l.py.announce) the official change in feature release
policy (the 6-12 month target instead of a 6 month target).
>>Thomas Wouters:
>>> There is no technical reason to do just N-1. You can branch of as
>>> often as you want (in fact, branches never disappear, so if we
>>> were building 3.5 ten years from now (and we would still be using
>>> CVS <wink GregS>) we could apply a specific patch to the 2.0
>>> maintenance branch and release 2.0.128, if need be.)
>>
>> No technical reason, no. It's just that N-1 is going to be similar
>> enough to N, particularly for any given bugfix, that it should be
>> "trivial" to keep the bugfixes in synch. That's all.
>
> I agree. The Tcl folks never issue patch releases when they've issued
> a new major release (in fact the patch releases seem to stop long
> before they're ready to issue the next major release). I realize that
> we're way behind with 2.0.1 -- since this is the first time we're
> doing this, that's OK for now, but in the future I like the Tcl
> approach a lot!
Okie-doke.
--
--- Aahz <*> (Copyright 2001 by aahz@pobox.com)
Androgynous poly kinky vanilla queer het Pythonista http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6
Three sins: BJ, B&J, B&J
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4