RetroSearch Browse

Thu Nov 4 00:17:59 CET 2004 · https://mail.python.org/pipermail/python-dev/2004-November/049751.html

Anthony Baxter wrote:
> 1. Include/patchlevel.h
> 2. Doc build (depends on 1.)
> 3. Misc/NEWS, Lib/idlelib/NEWS.txt, Lib/idlelib/idlever.py
> 4. PCbuild/BUILDno.txt, pythoncore.dsp
> 5. Tag the tree (depends on 1, 3, 5)
> 6. export/build the tarballs (depends on 5)
> 7. Build the windows release (depends on 2, 5)
> 8. Update the webpages, sign the files (depends on 6, 7)
> 9. Send the email (depends on 8)
> 
> 
> Stage 2 is a Fred thing, stages 4 and 7 are Martin, most of the rest
> are things I do, although Fred will often do 1 because he needs it
> to do 2, and the timezone thing makes it easier for him to just do
> it.

It would be possible to automate the bumps to version numbers, and
you don't have to be on Windows to do 4, anymore (as the project
file is now a fairly stable XML file).

Also, it would be possible to bump version numbers immediately after
a snapshot (alpha, beta) release, rather than just before. I tend
to forget that I have to do 4, and remember at earliest when you
announce the freeze.

> (*) The names 'Fred', 'Martin', and 'I' are just the names of the
> current set of release people - feel free to substitute roles in
> there instead.

I think it should be possible to come up with a release process that
combines Fred's and my role, wrt. documentation creation (I create
the chm file); theoretically, whoever builds the documentation should
be able to do so on Windows as well.

Also, I think it would be good to eliminate Fred's role altogether:
the documentation build process should be much more automatic, and
less relying on third-party tools. I think aiming at rewriting ht2html
in Python for 2.5 would be a worthwhile goal (I have dropped the
idea that conversion to xml would be worthwhile).

Then, the release manager could trivially build the documentation.
For that to work, it is necessary that the documentation builds out
of the box; for that to happen, it is necessary that a broad audience
can build the documentation, so that problems are detected long
before the release (i.e. short after a checkin - or better yet,
before). For the PostScript/PDF release, one certainly needs TeX,
but that is free software.

The same could be said about the Windows release, except that we
stand little chance of ever dropping the requirement for special,
non-free tools (Windows, MSVC). However, anybody possessing these
tools and owning a sufficiently powerful machine should be able
to release Python.

Regards,
Martin

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-November/049751.html below:

[Python-Dev] Re: interlocking dependencies on the path to a release