Hi Greg! > 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). A lot of software projects fix this by writing proper commit messages and then dump the commit messages for a release and probably just reformat and fix them. Obviously that requires to have one useful commit instead of a ton of tiny ones. These things are easy with distributed RCSs - you just create a topic branch, hack and then merge it into one useful commit and apply that to your master branch. > 3) Gathering the auxiliary data files together (easy to miss things here as > well). What about keeping them in a revision control system? > 4) Making source-only, overlay, and combined tar balls (simple, but I've > still screwed this up in the past). This is something which could be done automatically with make and friends. Once defined properly, it should be easier to do and harder to forget things. Also - looking at 3) there are tools like mr which allow to work with several independent repositories and merge them. > 5) Checking compile and building for the few supported systems (sometimes > days of delay and looping back to step 1). If it would be easier to create a new release, you could release a -RC version and wait for feedback. So finding a fast way to create releases would fix that point for large parts. > 6) Uploading release to website locations and relinking everything, while > archiving the old stuff (painful but straightforward enough). That sounds like a task for merging all locations into one so people could go to one place and retrieve everything from there. Generally something like redmin or trac would be nice to have as bugtracker and central plce to browse repositories. > 7) Updating man pages on website (usually comes last and often forgotten > altogether). What about doing that with a cronjob which pulls the manpages from cvs/git/whatever and builds the html version automatically? > 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). Same issue here - if making a release would be easy and automated, this step would be easy and fast to do, too. > 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. I think there are a lot of things which could be automated. I know projects which are run by one developer mainly and they release several times a year - which is pretty easy as the only thing you need to do is to change the version number and type make dist. There are a lot of platform-independent tools which help with such tasks these days. Let me know if I can help you with these things. Cheers, Bernd -- Bernd Zeimetz Debian GNU/Linux Developer http://bzed.de http://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F _______________________________________________ Radiance-dev mailing list [email protected] http://www.radiance-online.org/mailman/listinfo/radiance-dev
