[Python-Dev] Re: Stability and change

[Skip Montanaro]

    >> Let's postulate a Linux-like development process (at least w.r.t. CVS
    >> branches) and that the even-numbered minor numbers are the so-called
    >> experimental branches.

    Anthony> On thinking about it some more, I don't think I like the "even
    Anthony> == experimental, odd == stable" approach. 

I only postulated that because people seem to have been calling "2.1.x"
the Garth branch.  I don't really care one way or the other, and having the
same even-odd meaning as the Linux kernel means you won't fight the tide of
people who already know that way of doing things.

    Anthony> I'm also not so keen on the version-itis that I think having
    Anthony> multiple active branches will lead to. I look at Perl and I go
    Anthony> "ick".

So do I, but generally for different reasons.  :-) I don't think the
transition from 2.1.3 to 2.1.4 would have the same weight and corresponding
need for attention that it does today.  As an example, consider that serious
bug that was just discovered and fixed.  Once checked in and tested, Guido
should have been able to say, "okay, time for a point release", after which
a "few buttons get pushed" (hand wave, hand wave) and a new release appears
on SF.

    >> For this to work, a number of things have to happen.  First, the
    >> effort required to actually cut a release have to drop dramatically.
    >> Even all the editing of files to replace 2.1.2 with 2.1.3 needs to be
    >> automated.

    Anthony> The editing of files is completely and utterly the least of the
    Anthony> problems.  It's mostly a matter of pushing the right buttons on
    Anthony> the right web interfaces, that sort of thing. Now while this
    Anthony> could be automated, there's not a lot of point. Since 2.1.2,
    Anthony> the sourceforge interfaces for doing a file release have
    Anthony> changed, slightly. Not so much that a human can't figure it
    Anthony> out, but it'd stuff any automated systems completely.

That wasn't what I was referring to.  I was referring to the spate of
checkins where people have to advance version numbers prior to a release.  I
would hope that could be automated.

    >> Getting from "let's cut a release tomorrow" to "2.1.4 is released"
    >> should not be much more labor than running "make dist" and sticking
    >> it on SF, at least on the Unix side of things.

    Anthony> I wish!  Have a read of PEP 102. 

Obviously, if what I have in mind is going to work, PEP 102 is going to have
to be streamlined quite a bit.  Maybe that's not possible.  If that turns
out to be a significant barrier, the notion of "lighter weight" releases
probably isn't going to work.

    >> I don't know what's involved in making a Windows installer, but
    >> somebody besides Tim should be able to do that too.

    Anthony> I assume nothing. 

The fact that Tim owns that process and nobody else seems willing to pick it
up suggests otherwise.

Skip