How to release a version onto SourceForge

Created by: btodoroff, Last modification: 25 Jan 2006 (22:32 UTC) by xing

Change version in code

  1. Confirm the release version is correct in kernel/setup_inc.php. Commit any changes to CVS as necessary.

Archive Generation

archive generation has been summarised in the file ~/bin/
to use it, execute the file and use the new version number as argument:
e.g.: . ~/bin/ x.y.z

we need to generate a number of different archives for different users and requirements.

Create tar.gz file

  1. SSH onto
  2. sudo su - bitweaver
  3. From the Bitweaver home directory and execute the ~/live/install/ bitweaver Rx script, where Rx is the release you're building for. This checkouts the latest CVS of BW, cleans it up, and prepares it for distribution. (should be possible to us the command: freshbuild)
  4. The script creates a weekly build tar file in the Bitweaver home directory. Rename the bitweaver_bitweaver_wb_yyyyweekww.tar.gz file to the appropriate name ie bitweaver_x.y.z.tar.gz where x is the major revision, y is the minor revision and z is the release eg bitweaver_1.0.1.tar.gz
  5. Copy the renamed file to ~/builds directory

Release Test

  1. download the new file by visiting
  2. extract and install the new version of bitweaver solely following the onscreen instructions and watching for any issues.
  3. if issues were found, fix these and restart the ReleaseProcess

Create zip file

  1. mkdir ~/test in Bitweaver home directory
  2. tar xvzf bitweaver_x.y.z.tar.gz -C ~/test to extract a copy to test directory
  3. cd ~/test
  4. Create a new zip file, using zip -r bitweaver
  5. Move the file to ~/builds directory mv ~/builds/

Create bz2 file

  1. Create a new bz2 file, using tar cvjf bitweaver_x.y.z.tar.bz2 bitweaver/
  2. Move the file to ~/builds directory mv bitweaver_x.y.z.tar.bz2 ~/builds/

Create rpm file


Archive Testing

  1. execute the testing procedure for all the different archives if possible.


  1. Return to the Bitweaver home directory cd
  2. Remove test directory rm ~/test -rf

Upload files to SourceForge

  1. cd ~/builds
  2. Using anonymous ftp - upload the previous *.gz, *.zip and *.bz2 files to
    • ftp
    • Name ( anonymous
    • Password:
    • ftp> cd incoming
    • ftp> bin
    • ftp> hash
    • ftp> prompt
    • ftp> mput bitweaver_x.y.z.*
    • ftp> bye
  3. Login as SF admin at
  4. Go to Admin / File Releases
  5. At the bottom of the page, click Edit Releases on bitweaver Package Name
  6. At the top of the list, should be the previous release. Click the Edit this release link
  7. Scroll down to Step 2
  8. Select the check boxes for the 3 files you uploaded previously
  9. Click Add files and/or Refresh View
  10. Scroll down to Step 3
  11. For each of the individual files
    • files from the previous release, change the Release drop down box to bitweaver: Release - past releases
    • change the Processor drop down box to Platform-Independent
    • change the File Type drop down box to the appropriate extension
    • Click on the Update/Refresh button for that file
  12. Scoll to Step 1
  13. Change the:
    • Date - to todays date
    • Release Name - to Release x.y.z eg Release 1.0.1
  14. Click Submit/Refresh at the bottom of the page
  15. Scroll down to Email Release Notice
  16. Check the I'm sure box
  17. Click Send Notice

Final tests

  1. ensure that the uploads to sourceforge were completed successfully by downloading the files and extracting them. there should be no need for further testing if the testing stages above were executed.

CVS tag

  1. finally add a CVS Tag by doing: cvs rtag -r Rx Rxyz bitweaver e.g.: cvs rtag -r R1 R103 bitweaver


  1. Annouce on
    1. IRC
    2. Mailing List
    3. custom module
    4. Forums
    5. Articles
    6. Newsletter
  2. Revisit MediaBlitz to spread the word
    1. If you are too lazy to do the MediaBlitz thing, at least update the wikipedia page
  3. Add upgrade information to bitweaverUpgrade
  4. Update the bitweaver release module
  5. Update ReleaseSchedule
  6. Edit the file /home/bitweaver/live/bitversion.txt on packard and add appropriate version
  7. udpate version number in kernel/setup_inc.php to next release number + add beta as release level

New Releases

So how does bitweaver handle development of new releases?

At any time there are 3 active versions of bitweaver refered to as STABLE, TESTING, and DEVELOPMENT. We intend to follow the spirit of the debian release process.


This is the latest stable release for production use. This is STABLE and we mean STABLE, and have very high standards. If you need bitweaver in a production environment, this is for you. Only changes allowed here are to fix major bugs. Bug fixes here are pushed forward to TESTING and DEVELOPMENT.
These will be packaged as <edition>_FR1. If additional fixes are deemed necessary, packages called <edition>_FR2, FR3, ect.


This is the code being prepared for the next realease. This code should be considered very useable for a live site. No new features are added, but features are tested and fixed. Bugs are also fixed here, and those changes get pushed forward to DEVELOPMENT.
As realease gets close, we will periodicaly package release canidates called <edition>_RC1, <edition>_RC2 ect...
A release candidate, if good enough, will be transformed to a STABLE version if the TestProcess shows that it is OK. In practice it might happen that one or two critical bugs gets fixed before moving an almost good RC to a stable version if it is reasonable to belive that these corrections has few feature interactions.


This is the cutting edge and where new features get added.
Periodic tarballs will be made availible.

Both TESTING and DEVELOPMENT will produce weekly builds named <edition>_WB_<date>.</date></edition></edition></edition></edition></edition>