Making a blender release

Version: $Id: blender_release.html,v 1.6 2001/02/09 13:06:06 hans Exp $

1. Preparations
2. Upping the version number
3. Beos
4. Cleanup
5. Logging in on all machines
6. Starting the compile
7. Testing
8. Making the distributions
9. The windows installer
10. Uploading
11. Limited release
12. Making release notes
13. Full release
14. Mail users
15. Tagging
16. Finishing touch

1. Preparations

Make sure that the developers know that you are going to do a release. Ask them to finish their work, to test it and to commit it. Make sure they only commit bug fixes while you're working on the release, they should not commit new development.

Ask systemmanagement about the status of the compile and test machines. Make sure everything is available.

Plan at least two days for a full release. It helps to build debug versions before the first day to ease testing. Here's a possible schedule:

- build debug versions overnight
- test the next day and do some bugfixing
- do a release build on the second day
- relaese these at the end of the day

Make sure all the developers are present during these days. In case of problems the responsible developer can solve it probably quicker than you can, and you can focus on making the release.

Inform Bart on the new release. Ask him to make a tutorial on the new features. Ask Joeri if he can make a demo file and a new splashscreen.

2. Upping the version number

Changing the splashscreen...

In ~/develop/release/datafiles/ there is a c-file called datatoc.c . Compile this file on your favorite platform by doing a:

> cc -o datatoc datatoc.c

datatoc converts a binary datafile to a compilable c-file. This way you can incorperate images in the blender binary.

Anyhow:

  • rename the splash image to splash.jpg
  • execute datatoc: 
     > datatoc splash.jpg
  • this generates splash.jpg.c . Ignore the output size report of datatoc, it's not accurate. Copy splash.jpg.c over the existing file in blender/src
  • Up the version number in blender/src/blender.c (look for G.version) and in develop/release/VERSION .
  • compile blender on your favorite platform and test it

    Commit src/splash.jpg.c and src/blender.c and (in another commit we use more repositories at this moment) release/VERSION

    3. Beos

    Reboot the beos machine. Beos doesn't have a stable nfs implementation. If you don't reboot, be prepared for all kind of errors about files not being vissible to beos. i.e.

    /bin/cp: text/README: Unknown Error (-2147418112)

    in this case text/README was changed after the nfs mount.

    You can reboot beos remotely:

    > telnet beos (usercode and password are beos)
    > shutdown

    After the reboot login again and mount your home directory. Mine can be mounted by:

    > mount_nfs repo:/home/frank /boot/home/frank 1007 1007

    Where 1007 is my uid on the server. After that I do a:

    > cd /boot/home/frank
    > source ./beos.sh

    beos.sh contains: 

      export HOME=`pwd`
  export SRCHOME="$HOME/develop/source"
  export MAKEFLAGS="-w -I $SRCHOME --no-print-directory"
  export NAN_TARGET=BLENDER2
  export PATH="$HOME/bin:/boot/home/config/bin:/bin:/boot/apps:/boot/preferences:/boot/beos/apps:/boot/beos/preferences:/boot/develop/tools/gnupro/bin"

    4. Cleanup

    Remove you ~/obj directory to make sure that all old objects are removed. 

      cd ~/develop/lib && cvs update
cd ~/develop/release && cvs update
cd ~/develop/source && cvs update
    Make sure that you have all recent files without any local modifications. I usually do a ((t)csh presumed): 
      cvs status |& grep Status: | grep -v Up | less
    afterwards. This should report on all modified or missing files...

    5. Logging in on all machines

    What Frank usually does is this:

    Start a putty on a windows machine. Putty is a SSH client. With putty I start a ssh session to the server.

    Once on the server I start up screen. Screen gives you multiple 'windows' in the same terminal window. You can find the binary in ~frank/bin/screen . Copy my .screenrc for some nice default settings.

    In my .tcshrc I have defined a prompt that changes the window title of the putty client. That way you can see to which machine you are currently connected.

    From within screen I start up 9 different connections to the compile machines. I can switch to the different sessions from the keybord. But the best thing is: I can close my connection to screen and reconnect later on from a different location and have my sessions with their output back. So I can start the compiles at work, and check from home what the result was.

    Anyhow. Ask for a demonstration if you would like to use the same setup, or start 9 different xterms or...

    Login to the different machines. Currently these machines are: 

    - server    (freebsd-3.4*)
- quad      (irix-6.2)
- ito   (2) (irix-6.5)
- glibc     (linux-glibc2.1.2-i386*)
- alpha     (linux-glibc2.1.3-alpha)
- linuxppc  (linux-glibc2.1.1-powerpc)
- ultra     (solaris-2.6-sparc)
- win2k (1) (windows)
- beos  (1) (beos)
    *1 You can use ssh to login to most machines. There are two exeptions: beos and win2k . Use telnet to login to these machines. For beos use usercode == password == beos . On win2k you can use your own usercode and NT-password. This NT-password should be equal to the samba password on server.intra.blender.nl , otherwise win2k won't be able to mount your homedirectory. And your usercode should be added to /etc/passwd on win2k .

    *2 compiling on ito over nfs is terribly slow if you use the Eindhoven server. Instead you can use fw-adm as a fileserver.

    6. Starting the compile

    On each machine: 
      cd ~/develop/source && make debug all

    on ito make might point to the SGI-make for you. Use gmake there.

    7. Testing

    While you're making the release and testing blender files you'll probably want to test with the blender debug versions.
    Before you release the final blender executables you might want to test the binaries in the distribution files as well.

    On the server in /home/develop/releasetest you'll find some test files. Each file contains a short description on what kind of test should be performed. NOTE/TODO: rendertest.blend is corrupt

    8. Making the distributions

    If everything succeeds, you can make the distributions. On all systems go to the release directory: 
      cd ~/develop/release && make

    alpha always gives an error message: 

      tar: blender2.04-linux-glibc2.1.3-alpha/blender: file changed as we read it

    Make a new distribution by hand. On the server do: 

     > cd ~/obj
 > tar cvf  2.10/blender2.10-linux-glibc2.1.3-alpha.tar   blender2.10-linux-glibc2.1.3-alpha
 > gzip --best  2.10/blender2.10-linux-glibc2.1.3-alpha.tar
 > rm -rf blender2.10-linux-glibc2.1.3-alpha

    Another error message that you will get is on BeOS. Zip reports: 

     zip warning: couldn't write complete file type

    You can ignore this one.

    9. The windows installer

    First you will have to have made the zip distribution in win2k (make in develop/release). This creates a directory with all the input files needed for the installer. Now go to win2k, connect all its cables ;-) and open an Explorer window. Go to C:\Blender\Installer:

    First open 01.welcome.rtf with Wordpad and edit it. There's a version number in this file. Change the version number, save the file and quit.

    Next open 00.installer.adx, the Installer definition file:

    Click on Next and change the version number:

    Click 25 (!) times on Next. Change the version number twice in the window below:

    Three more times Next until you're here:

    In this windows you can check all settings. Click 'Show Setup Wizard' for an Installer preview. When satisfied click on 'Create'. This creates server:~/obj/blender2.xx-windows.exe AND saves the current settings to disk, overwriting the old settings. Test the installer. When satisfied rename the .exe file on the server to the correct version number and move it to the correct location.

    10. Uploading

    All distribution files now are collected in a subdirectory in ~/obj . Copy these files with scp to your home directory on www.blender.nl . These files have to be copied to two different locations later on. And if you're going to overwrite existing files (in case off a quick fix), you don't want users end up with corrupted downloads when you scp them directly to their download location. 

     > scp ~/obj/2.10/* www.blender.nl:

    I have a symlink in my homedirectory on www.blender.nl that points to the ftp directory: ftp -> /home/ftp/pub/. After I've uploaded the files, I copy them to the ftp directory. 

     > cp blender* ftp
   - or -
 > cp blender* ftp/.private
   - or -
 > cp blender* ftp/beta

    11. Limited release

    Usually we do a small pre-release to test blender in the field. Windows and Linux are the most appropriate platforms for this. Upload the distributions to ftp/.private and post this in the news & chat discussion area.

    12. Making release notes

    To be done...

    13. Full release

    Copy all files to the ftp directory. Copy them to the http-download directory as well: 

     > cp blender* /home/ftp/pub/
 > cp blender* /usr2/local/www/data/download/packages
    Change the version numbers in /usr2/local/www/data/download/version.php. This will update the download pages. Check if all links in the download pages still work.

    Make an announcement in the bugs, news & chat and gameblender discussion areas.

    14. Mail users

    NOTE: the release_log.txt file is very confusing. This must be fixed

    Collect all e-mail addresses from release_log.txt from people that reported a bug that is fixed in this release. Mail them that there is a new release and that a bug they reported has been fixed.

    Copy all e-mail addresses in a file named addresses. It should look like this: 

    ------------------------
Admin@angelseven.com
Readalot38@Aol.com
WP@blender.nl
bart@blender.nl
cwant@computy.ucs.ualberta.ca
------------------------
    Create the mail you want to send and copy it in a text file called mail. Here's an example: 
    ------------------------
Date: Thu, 28 Dec 2000 15:02:38 +0100 (CET)
From: Frank van Beek 
To: TO_ADDRESS
Subject: blender 2.10 release
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi all,


Last week blender 2.10 was released. One of the bugs reported by you has
been fixed, or an enhancement request done by you has been implemented in
this release.


You can read all about it here:

 http://www.blender.nl/showitem.php?id=113


Most releases can be found here:

 ftp://ftp.blender.nl/pub/beta/


Happy blending !

Frank.

---
Not A Number,  van Eeghenstraat 84,  1071 GK Amsterdam,  the Netherlands
Blender, free 3D software for the new millennium   http://www.blender.nl
------------------------
    Test the mail: 
     > set i=frank@blender.nl
 > cat mail | sed s/TO_ADDRESS/$i/ | sendmail $i
    And check the mail in your favorite mail client. If it looks OK you can start spamming.... 
     > foreach i (`sort addresses | uniq`)
 >    echo $i
 >    cat mail | sed s/TO_ADDRESS/$i/ | sendmail $i
 > end

    15. Tagging

    Make sure that you don't change the source files before you tag them. Usually developers will start committing right away and you've been doing cvs updates continuously. Otherwise use cvs update -D to go back to the sources that were used for the release. Use 'cvs status |& grep Status: | grep -v Up' to make sure you're tagging the correct versions.

    Use the correct tag name and add the tags with: 

      cd ~/develop/source && cvs tag blender-2-11-release
cd ~/develop/release && cvs tag blender-2-11-release
cd ~/develop/extern && cvs tag blender-2-11-release
cd ~/develop/lib && cvs tag blender-2-11-release

    16. Finishing touch

    Remove all fixed buglines from ~/develop/source/blender/release_log.txt and commit this file. TODO shouldn't this be before the tagging ?

    Update this document. ;-)