BIRCH Stable Release Checklist

From Bioinformatics.Org Wiki

Jump to: navigation, search

Mystica Arrow set (with deep) 1.png [return to BIRCH Project]


Contents

Clean out old files, especially from bin directories.

These will typically have a .bak or .old file extension. They usually represent binaries that we might want to keep around for awhile after installing a new version of a program, to make it possible to revert to the old version if necessary.

Run htmldoc.py on BIRCHDEV

If old documentation has been removed from birchdb, make sure to run htmldoc.py to update the documentation pages.

Review and document recent changes

All changes should be documented in BIRCHDEV/doc/ReleaseNotes.html

Update splash screen for BIRCH launcher

The file birch_white_version.png is displayed in the birch launcher, with the version number for the current version. This number needs to be updated in the graphic. See the instructions in /home/psgendb/BIRCHDEV/dat/birch/hints_for_birch_white_version.txt.

Generate a new Development Release, including binaries

a. Revise graphics for birch launcher to show Development release number.

Once a new stable version of birch has been frozen, Go to BIRCHDEV/dat/birch and follow the instructions in hints_for_birch_white_version.txt. For example, if the stable version is 3.30, version should be changed to 3.40D, to indicate the new Development version.


b. Edit BIRCHDEV/build/makeframework.excludefile to exclude all unnecessary files from the $birch/java directory. Mostly these are in the various bioLegato versions. Next, create a development version of the framework file:

makeframework.csh

Test Development Release on all supported platforms

Generate a Stable Release, but don't list it on the download page.

a. Revise graphics for birch launcher to show stable release number.

Go to BIRCHDEV/dat/birch and follow the instructions in hints_for_birch_white_version.txt. For example, if the Development version is 3.30D, change that to 3.30, to indicate a stable version.

b. Update the development version of the binaries

On CCL: makebin.sh linux-x86_64

On peacock: makebin.csh osx-x86_64

Binaries osx-x86_64 must be generated on peacock, respectively, and uploaded to the Development directory.

c. Create a new birch framework


makeframework.csh -v  version_number

This script creates a new snapshot called framework_version_number.tar gz. It also copies the tar archives containing the development version of the binaries to new files with the version number. This means that the binary files need to be up to date in the development verison before running makeframework.csh.

d. Add the new version number to birchtally.cgi

Login as birch on flamingo.

cd /usr/lib/cgi-bin/birch

Add the new version number to the list of valid versions in birchtally.cgi.

    Versions = ['D', '3.00','2.96']

birchtally.cgi will fail to record a birch download if its version number is not in the list.

Test on other systems

as in step 3

Special Note for /home/psgendb: Sometimes the system leaves stale NFS handles in various directories. The names of these files begin with ".nfs". The reason appears to be that when updating using birchadmin, temporary files created by birchadmin and birch don't get deleted until those Java programs terminate. The result is that the .nfs handles can't be deleted by the script. You still get a full update, but any files deleted from the BIRCH framework since the previous update will remain. This doesn't cause any problems I have been able to see, other than taking up some disk space.
Solution: On NFS systems, run getbirch.jar from the command line, rather than through birchadmin.

/home/psgendb/local/script has a script called checknfs.sh, which uses find to search for stale NFS handles, prior to doing a BIRCH update. Although they belong to the owner (psgendb), only someone with sysadmin privileges can remove them. It is therefore advisable to run this well in advance of updating /home/psgendb:

cd /home/psgendb/local/script
./checknfs.sh checknfs.dirs > checknfs.out

As a control, it's a good idea to put a dummy NFS handle into one of the directories just to prove that the script will find these. Call it .nfsjunk or something like that.

When satisfied, change the symbolic link CURRENT to point to the new version.

eg.

cd /home/psgendb/FTP/BIRCH
ln -s 2.9 CURRENT

In this example, GetBirch will see version 2.9 as the current version for download.

Announcements

Version home page

Edit the BIRCH announcement page at http://home.cc.umanitoba.ca/~psgendb/local/public_html/BIRCHannouncement<version>.html

This file is just a copy of the $doc/ReleaseNotes.html. There is still an issue with inline links needing to be changed when the file moves to this directory.

Since it's often good to include hypertext links to new features, we need to install the updated BIRCH version to /home/psgendb, so that the links can point to the new features.

Next, update local/public_html/News/BIRCHNews.html. This is the file that shows up in an inline frame on the BIRCH home. The next time current BIRCH users load the BIRCH home page, they will see the contents. It is used for announcing new releases, videos, or other newsworthy items.

BIRCH mailing list

i) Copy /home/psgendb/local/public_html/BIRCHannouncement<version>.html to /home/frist/software/BIRCH/Distribution.

ii> modify as follows:

Email message files are HTML, but begin with Subject: and a blank line For compliance with anti-spam laws in Canada and elsewhere, the message begins with unsubscribe instructions.

Example:

Subject: BIRCH 3.10 Bioinformatics System

<HTML><body>
<table border="1">
<tbody>
<tr>
<td>To unsubscribe, reply to this message with the word UNSUBSCRIBE in the Subject line.</td>
</tr>
</tbody>
</table>
<h1>BIRCH 3.10</h1>
<i>the rest of the message....</i>
</body></HTML>

iv) Do a test mailing using


python mailer.py test.mailinglist.txt BIRCH3.10announcement.html

This script mails htmlfile to the specified mailing list.


v) If the mail message looks good, send it to the actual mailing list:

python mailer.py mailinglist.txt BIRCH3.10announcement.html


Mailing lists:


Note: It probably makes sense to send out announcements to the mailing lists one list per day. Usually in the first 24 hr. after a mailing, you get a few of Mail Delivery System messages saying that a user is not found. This way, you know which mailinglist to delete an email address from.

Before doing further announcements, give people a week or two to see if there are problems.

Other places to announce

Teaching bioinformatics! - Let's find places that focus on teaching bioinformatics. A great deal of the potential for BIRCH is in teaching. This will be especially true at institutions that don't have huge budgets, but can afford a small server with free software. This could be the most effective way to increase the BIRCH user base.

How about an article in a teaching journal (or, a research journal that will publish teaching articles) eg. "Experiential bioinformatics - Using BIRCH to train 21st century biologists."

Personal tools
Namespaces
Variants
Actions
wiki navigation
Toolbox