On Sunday 15 October 2006 21:23, Steve Holden wrote: > Martin v. Löwis wrote: > > Steve Holden schrieb: > >>>>The other thing to watch out for is that I (or whoever) can still do > >>>> local work on a bunch of different files > >>> > >>>the point of my previous post is that you *shouldn't* have to edit a > >>>bunch of different files to make a new release. > >> > >>Indeed. I seem to remember suggesting a while ago on pydotorg that > >>whatever replaces pyramid should cater to groups such as the release > >>team by allowing everything necessary to be generated from a simple set > >>of data that wouldn't be difficult to maintain. Anthony has enough on > >>his plate without having to fight the web server too ... > > > > There is always some sort of text that accompanies a release. That has > > to be edited to be correct; a machine can't do that. > > OK. > > ^everything^the content structure and many of the files^
If you compare the various pieces that make up the release pages, you'll see that much of it is boilerplate, true. There's two cases worth mentioning: First release of a new series (2.4.4c1, 2.5a1). This involves making the new directory and all the little fiddly files. In practice, this is done by recursively copying the previous release and removing the .ssh directories so that it can be re-added. I then go through and update the files. Subsequent release. This is still largely a manual process - I search for all the references to the previous release, update them, then read through it for missed bits. I then update the text bits that need to be changed. There's all sorts of minor variations there - for instance, often in a non-final release, we don't have an unpacked version of the documentation (but sometimes we do, wah). The killer bits for me are all the other places. For instance, updating the sidebar menu quicklinks for 2.4.4 to 2.5. There's just too many files, and the structure of pyramid's files still doesn't make sense to me. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
