[Python-3000] The release process

Barry Warsaw barry at python.org
Sun Mar 2 00:03:35 CET 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

Maybe.

> In any case, I'm willing to help with welease, but not with yet  
> another
> 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  
release versions.

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.

Cheers,
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR8ngyHEjvBPtnXfVAQKYaAP+JzIj8HiwVYIJLMyxh+Glq57YQozOh2bB
XILPBwUyppBBkezcT6IWAnawo5YUGXwg1tJjS/OsqSnIoajnRQCzzR6X896qXUAn
asgXKTydmf553iSD03OG4K38UsdeD6uPUWN9zg/bceKaH2GM72p6md3Wepof4DuE
UdTGgXENXOI=
=uKmC
-----END PGP SIGNATURE-----


More information about the Python-3000 mailing list