[Python-3000] The release process
barry at python.org
Sun Mar 2 00:03:35 CET 2008
-----BEGIN PGP SIGNED MESSAGE-----
On Mar 1, 2008, at 5:37 PM, Martin v. Löwis wrote:
>> With apologies to Anthony, welease is crack. I made pretty good
>> progress once I ditched it and starting doing things manually.
>> Between now and the next alpha I intend to work on a command line
>> script to help with releases. If you're interested in helping, let
>> me know.
> I guess every release manager is free to come up with his own set of
> tools, but I feel you've given up too quickly (or started too late -
> perhaps a test release run a few days before the release would have
> In any case, I'm willing to help with welease, but not with yet
> release tool. If you primarily complain about the GUIness of welease,
> I could help with a command line version of it.
The dependency on gtk is unnecessary and means it can effectively only
be run on Linux. Specifically it means I can't do releases on OS X.
I don't see much benefit in having a gui tool for doing releases.
Some of the problems I had include having to run glade3 in order to
update the menus which allow you to choose which release you were
going to make. It only new about py24 and 25 maintenance. No knock
on Anthony there, since those are the releases he had to make, but I
shouldn't have to edit the interface description files to add new
Also, the scheme to compare IDLE versions seemed way off. Maybe
that's another thing that makes sense for py24 and py25 but it
definitely didn't work for py30.
The much more serious problem, and where I stopped, is that welease
broke on code containing the with statement. I don't remember the
details because at that point I was pretty tired and hadn't made any
progress on the releases, but I /think/ the problem is that welease
runs on a different version of Python than it's checking so it can't
handle syntactic differences and such.
The kind of tool I think we need is a fairly straightforward command
line tool, but one that would not just check that things are done, but
also do them. E.g. the tool would keep track of all the little places
where version numbers and copyright years need updating. The tool
would actually make those changes, and using $EDITOR would show them
to you for confirmation. It would pause at steps that require
coordination, such as when things need to be committed or signed, or
when you're waiting from input from others. It would have a dry-run
mode and it would fairly closely follow PEP 101.
Anyway, that's the kind of tool I plan on building (or perhaps with
help from others -- hi Benjamin) for the next alpha round.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
-----END PGP SIGNATURE-----
More information about the Python-3000