History of ReleaseProcess
Version 12
ReleaseProcess
How to release a version onto SourceForge
Created by: Stephan Borg, Last modification: 30 Jul 2005 (00:48 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
- Copy the file to ~/builds directory
Create bz2 file
Create rpm file
TODOUpload files to SourceForge
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>