Hi Bernd, Most of the hassle with putting together a new release can be resolved with website changes we're planning for next year. Right now, we have depositories in a few different places, automatic updates that sort-of work most of the time, and documentation that is spread all over the place. It's really more a matter of organization and putting others in charge than it is one of CVS and the way that works.
To give you an idea, posting a new release involves: 1) Putting together the latest source and creating a version in CVS (this is the easy part). 2) Updating documentation with new release information (easy to forget things, and I do). 3) Gathering the auxiliary data files together (easy to miss things here as well). 4) Making source-only, overlay, and combined tar balls (simple, but I've still screwed this up in the past). 5) Checking compile and building for the few supported systems (sometimes days of delay and looping back to step 1). 6) Uploading release to website locations and relinking everything, while archiving the old stuff (painful but straightforward enough). 7) Updating man pages on website (usually comes last and often forgotten altogether). 8) Making announcement to user group of new release availability. 9) Depending on feedback, possibly making a patch release to fix build problems encountered by users (sigh). Very little of this can be automated, which is part of why it doesn't happen very often. Having a HEAD version has been a huge help, since people who want the latest bug fixes and feature adds can get them in real-time, at the expense of doing their own compiles and taking a little risk that their results will not agree with earlier runs. Radiance development benefits greatly from the feedback of these brave users and allows for build fixes along the way, so that patch releases are not as necessary as they used to be. Even if we could streamline the release process, I still don't think we'd want to do it more than once a year or so. People who want the latest and are willing to deal with any problems along the way can grab the HEAD whenever they like, and those who prefer stable releases and precompiled binaries probably don't want to be updating their systems multiple times a year. The one thing we will be soliciting help on is step 5 above, building and testing on different systems in advance of an official release. We need to gather volunteers and create some useful test cases for that process, and this is something we plan to do this coming year, given the time and personnel. Cheers, -Greg > From: Bernd Zeimetz <be...@bzed.de> > Date: November 30, 2010 1:49:08 AM PST > > On 11/29/2010 09:31 PM, Gregory J. Ward wrote: >>> It's fixable by using src/rt/ambient.c from the HEAD distribution. >>> Given it's a known crash bug, pretty please, how about a release 4.1 >>> with a fix? >> >> If making a new release were less work, I would do it more often. As it is, >> it takes days of my time, and I never get it quite right. I don't really >> make new releases for bug fixes -- that's why we have HEAD. Since this bug >> has been there for years and years, and only recently manifested due to some >> change in FreeBSD, I don't think it affects all that many users. I do >> apologize for the inconvenience, but the next release probably won't happen >> until sometime in Spring. > > But it should be possible to do most parts of a new release automatically. My > guess is still that switching to a proper revision control system would make > things easier for you - using branches in cvs is a bit insane, but branches > would make it easy to prepare a new release. _______________________________________________ Radiance-dev mailing list Radiance-dev@radiance-online.org http://www.radiance-online.org/mailman/listinfo/radiance-dev
