History of ReleaseProcess
Version 13
ReleaseProcess
How to release a version onto SourceForge
Created by: Stephan Borg, Last modification: 30 Jul 2005 (01:25 UTC) by Stephan Borg
Change version in code
- Confirm the release version is correct in kernel/setup_inc.php. Commit any changes to CVS as necessary.
Create tar.gz file
- SSH onto packard.bitweaver.org
- sudo su - bitweaver
- From the Bitweaver home directory and execute the ~/live/bitweaver/install/bitweaver_build.sh 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.
- 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
- Copy the renamed file to ~/builds directory
- Annouce on IRC and mailing list, it is avaiable for testing
Create zip file
- mkdir ~/test in Bitweaver home directory
- tar xvzf bitweaver_x.y.z.tar.gz -C ~/test to extract a copy to test directory
- cd ~/test
- Create a new zip file, using zip bitweaver_x.y.z.zip -r bitweaver
- Move the file to ~/builds directory mv bitweaver_x.y.z.zip ~/builds/
Create bz2 file
- Create a new bz2 file, using tar cvjf bitweaver_x.y.z.tar.bz2 bitweaver/
- Move the file to ~/builds directory mv bitweaver_x.y.z.tar.bz2 ~/builds/
Create rpm file
TODOCleanup
- Return to the Bitweaver home directory cd
- Remove test directory rm ~/test -rf
Upload files to SourceForge
- cd ~/builds
- Using anonymous ftp - upload the previous *.gz, *.zip and *.bz2 files to ftp://upload.sf.net/incoming
<?php
$ ftp upload.sf.net
Name (upload.sf.net): anonymous
Password:
ftp> cd incoming
ftp> put bitweaver_x.y.z.tar.gz
ftp> put bitweaver_x.y.z.zip
ftp> put bitweaver_x.y.z.tar.bz2
ftp> bye
?>
- Login as SF admin at http://sf.net/projects/bitweaver
- Go to Admin / File Releases
- At the bottom of the page, click Edit Releases on bitweaver Package Name
- At the top of the list, should be the previous release. Click the Edit this release link
- Change the:
- Date - to todays date
- Release Name - to Release x.y.z eg Release 1.0.1
- Click Submit/Refresh at the bottom of the page
Announce
- Annouce on IRC and mailing list, it is avaiable for testing
- Revisit MediaBlitz to spread the word
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.STABLE
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.
TESTING
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.
DEVELOPMENT
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>