SquirrelMail - Webmail for Nuts!

Donations
News
About
Support
Screen shots
Download
Plugins
Documentation
Sponsors
Bounties

search site:

more search

SquirrelMail Developer's Manual: Project Administration Next Previous Contents

5. Project Administration

5.1 Webmail Release Instructions

Teamwork: Before beginning, coordinate the release with other members of the admin list to ensure proper time for verification and testing of release components (RPM, etc).
Usual sanity: Check the code over to make sure we are absolutely ready.
Documentation: Update Release Documents
1. Make sure that the ChangeLog is up to date - remember to put the release date in place of SVN at the top of the file.
2. Update the ReleaseNotes, keeping the same general format.
3. Compose a three to eight line message you'll post to mailinglists and forums. Include links. (While you're at it, make a simple HTML version of it as well, you'll need it later) Be BRIEF. Keep this message in your editor or on file for later on.
Gearing up: Update the version number strings at 3 places:
1. Variables in functions/strings.php ($version = '1.4.20', $SQM_INTERNAL_VERSION=array(1,4,20)).
2. doc/ChangeLog
3. doc/ReleaseNotes
SVN packaging:
1. Commit final changes to Subversion (doc/ChangeLog, doc/ReleaseNotes, functions/strings.php)
2. Tag SVN with the release number in the format webmail-release-X_Y_Z (webmail-release-1_4_20). Example:
  svn copy -m "Webmail version 1.4.20" \ https://squirrelmail.svn.sourceforge.net/svnroot/squirrelmail/branches/SM-1_4-STABLE/squirrelmail \ https://squirrelmail.svn.sourceforge.net/svnroot/squirrelmail/tags/webmail-release-1_4_20
3. Use the script make-release-webmail found in SVN under the util/ dir. The only parameter is the version to release. It will download the tagged SVN copy, pack it up nicely and upload it to SF.net. You will need the following tools: bash, svn, ssh, rsync, tar, gzip, zip, bzip2 and optionally rpmbuild.
4. Create a GPG signature for each of the newly created release packages. Typically, this can be done with:
  1. gpg -a --detach-sign --output squirrelmail-X.Y.Z.tar.gz.sig squirrelmail-X.Y.Z.tar.gz
  2. gpg -a --detach-sign --output squirrelmail-X.Y.Z.tar.bz2.sig squirrelmail-X.Y.Z.tar.bz2
  3. gpg -a --detach-sign --output squirrelmail-X.Y.Z.zip.sig squirrelmail-X.Y.Z.zip
  An example for how to verify that your signature worked would be:
  1. gpg --verify squirrelmail-X.Y.Z.tar.gz.sig squirrelmail-X.Y.Z.tar.gz
5. Upload your GPG signatures to Sourceforge.net. See the next step or see sf.net instructions or see sf.net upload protocols.
6. The make-release-webmail script's upload feature is dated and is currently commented out (even if you get that to work, you still need to upload your GPG signatures and use the instructions below to set the release file properties, etc.). SourceForge has made changes to their file management and release system more than once recently, not without much frustration for us. The following steps are how version 1.4.20 was uploaded in March, 2010.
  1. Since when logged in by sftp, creating directories seems to fail with a permission denied (sigh), first create the release directory ahead of time by using web interface at:
    https://sourceforge.net/project/admin/explorer.php?group_id=311
    For example, click to expand the "stable" directory and then click on the "gear" icon next to the "stable" directory and select to create a new folder, naming it with the release version (e.g., 1.4.20).
  2. Now, you can sftp to the release directory (this assumes you are in the (local) directory where you ran the make-release-webmail script):
    sftp username@frs.sourceforge.net
    Once logged in, here are the needed sftp commands:
    cd /home/frs/project/s/sq/squirrelmail/stable/1.4.20 put 1.4.20/squirrelmail-1.4.20.tar.bz2 put 1.4.20/squirrelmail-1.4.20.tar.bz2.sig put 1.4.20/squirrelmail-1.4.20.tar.gz put 1.4.20/squirrelmail-1.4.20.tar.gz.sig put 1.4.20/squirrelmail-1.4.20.zip put 1.4.20/squirrelmail-1.4.20.zip.sig put 1.4.20/squirrelmail-1.4.20/doc/ReleaseNotes
  3. Now you have to use the web interface to assign properties to the uploaded files:
    https://sourceforge.net/project/admin/explorer.php?group_id=311
    1. Navigate to the new release folder (e.g., stable ==> 1.4.20).
    2. Click on the ReleaseNotes file and tick the Release Notes checkbox.
    3. Currently, the interface seems to only support assigning properties to one of the release files, so click on the .bz2 file and check ALL the platforms, and select the correct release notes file.
    4. Click on each of the .sig files and label it as "GPG signature".
  4. Verify that SourceForge has automatically chosen to display the new release as the official release on the main SquirrelMail project page:
    https://sourceforge.net/projects/squirrelmail/
7. (huh: don't go to sleep before you're finished making the release)
Defrosting: Prepare SVN for continued development
1. Go back to your regular SVN development directory.
2. Update the version number variable in functions/strings.php by incrementing the incremental release number by 1 and adding ' [SVN]' after it ($version = '1.4.21 [SVN]';). Also, don't forget to update the $SQM_INTERNAL_VERSION array!
3. Add a new section in doc/ChangeLog for the new release, followed by ' - SVN'
4. Archive the doc/ReleaseNotes for this release like this:
  svn copy doc/ReleaseNotes doc/release_notes_archive/X.Y/Notes-X.Y.Z.txt
5. Commit all these changes to SVN with a note saying that it is ready for continued development.
Enable downloading: Update the download page for the SquirrelMail website.
1. SSH into sciurida
2. Change to the web directory for SquirrelMail (currently /srv/www/www/htdocs).
3. Edit download.php and change the version number as necessary (specifically, you need to update $stable and $stable_svn).
4. Edit plugin_query.php file and change version number. This file informs pupdate plugin users about new release.
5. Upload the md5 checksums and sha1 checksums that make-release-webmail calculated and your GPG signatures into the sums/ dir.
Blatant yelling: Announce the release to the World.
1. Post the release to the SourceForge news system. (you need to be a "forum moderator" to do this)
  1. Log into SourceForge.net and proceed to the SquirrelMail project page.
  2. Add a news item for this release in the SourceForge news system. (The 3 to 8 line message you've made)
  3. Submit the news, go preview it, and fix it if you did something silly. :)
2. Add a news item to the SquirrelMail webpage.
  1. Go to the address http://squirrelmail.org/admin and log in.
  2. Click on news.
  3. Create a brief news item titled in the format 'ANNOUNCE: SquirrelMail X.Y.Z Released'. Use the three to eight line message (you have to use HTML, no wiki pretty formatting here).
  4. Submit the news, go preview it, and fix it if you did something silly. :)
3. Send a message to squirrelmail-announce telling people about the release.
  1. Also, currently, it seems to have become convention that the message gets sent to all our other mailing lists: squirrelmail-announce@lists.sourceforge.net, squirrelmail-users@lists.sourceforge.net, squirrelmail-plugins@lists.sourceforge.net, squirrelmail-devel@lists.sourceforge.net, squirrelmail-i18n@lists.sourceforge.net
  2. Again, use your brief 3 to 8 line message
  3. The subject should read "ANNOUNCE: SquirrelMail X.Y.Z Released"
  4. Approve the message
    1. Log in to the squirrelmail-announce administrative interface.
    2. Choose "Tend to pending administrative requests"
    3. Read the message, make sure you made no silly mistake whatsoever, and approve of it
    4. Log out
4. Update freshmeat.net.
5. Update Wikipedia.

5.2 IMAP Proxy Release Instructions

SVN packaging:
1. Tag SVN with the release number in the format imap_proxy-release-X_Y_Z (imap_proxy-release-1_2_8). Example:
  svn copy -m "IMAP Proxy version 1.2.8" \ https://squirrelmail.svn.sourceforge.net/svnroot/squirrelmail/trunk/imap_proxy \ https://squirrelmail.svn.sourceforge.net/svnroot/squirrelmail/tags/imap_proxy-release-1_2_8
2. Use the script make-release-imap-proxy found in SVN under the util/ dir. The only parameter is the version to release. It will download the tagged SVN copy, pack it up nicely and upload it to SF.net. You will need the following tools: bash, svn, ssh, rsync, tar, gzip, zip, bzip2 and optionally rpmbuild.

5.3 Adding New Languages

Validate the translation: Before beginning, there are several things that need to be verified for the translation to be acceptable:
1. Copyright: Make sure it's OK to assign the copyright to the SquirrelMail Project. We won't accept translations with other copyright holders.
2. Validate what was translated: The typical starting point for translating the SquirrelMail core is the most recent 1.4.x translation pack release squirrelmail.pot file, the most current of which is found in SVN /branches/SM-1_4_15/locales/po. However, the most comprehensive list of strings (for both STABLE and DEVEL) is always found in the SVN trunk locales, which is also the starting point for making new language pack releases.
3. We want UTF-8: If the translation isn't already in UTF-8, push very hard to have the translator convert to UTF-8. SquirrelMail 1.5.x will soon be UTF-only, in which case we will stop accepting non-Unicode translations.
4. Inspect headers Compare the translation headers to one of the better ones already in the repository, such as Swedish ( sv_SE). Ask the translator to fix any problems with the headers.
5. We want two letter ISO 639-1: If the translator has chosen a language code with attached region code, work with them to understand if the region code is necessary. If at all possible, we want languages with just the language code ("de" instead of "de_DE"; the latter is in the SquirrelMail repository only for legacy reasons). Check other projects to get an idea of the region code is needed such as KDE, KDE, Gnome, Debian, Ubuntu, Fedora, Drupal, etc. Ideally, only the lower case two letter ISO 639-1 language code is used. If the region code is needed, make sure the language code is lower case and the region code is upper case ("pt_BR").
6. Sanity check: Have a look over the translation file(s) and make sure they look reasonable.
7. sec_remove image: Ask for a translated copy of the sec_remove_eng.png image file (renamed, of course, to sec_remove_<language>.png).
8. sec_remove strings: The sec_remove_eng.png string in the squirrelmail.po file should be "translated" to sec_remove_<language>.png. The string in the image itself ("This image has been removed for security reasons") is also in the .pot file and should be translated in the .po file.
Create setup.php: Each language has its own setup.php file found in the top-level language directory (alongside LC_MESSAGES). A good starting point is to look at an existing example such as the Norwegian ( nb_NO) one. See our explanation of the $languages array manual section.
Update ChangeLog.locales: Make a note of the new addition
Update i18n.php: Copy the contents of the language setup.php file created in the previous step into a block in the STABLE branch functions/i18n.php file.
Place translations in SVN trunk: The main translations (.po files - .mo files don't belong in SVN) should go in SVN trunk/locales/locale/<language>/LC_MESSAGES. There are two directories in the LC_MESSAGES directory for most languages: "plugins", which contains translations for plugins that are still coded such that translation files need to be placed within the plugin itself (obsolete). The "extra" directory contains other translation files for broken things (mostly plugins with missing or incorrect internationalization efforts). These all correspond to the .pot files we provide, so where the translated files go should be rather obvious. Properly coded plugin translation files belong in the top-level LC_MESSAGES directory.
sec_remove image: The translated sec_remove image file should be placed in the main locales images directory.
Update SourceForge: Add the language to the list of supported translations on the SquirrelMail project page by logging in as an administrator and going to: "Project Admin" --> "Project Settings" --> "Public Info" --> "Edit Trove Categorization" --> "Translations"
Update SquirrelMail manual: Update the supported languages list in the Developer's Manual ( "Supported Languages" in docs/devel/devel-3).
Add translator(s): Add the translation maintainer(s) to the TRANSLATORS file.
Update statistics: Add the translation team to the teamnames file.
Changelog: Add the new translation to the Changelog for both STABLE and DEVEL.

5.4 Updating Copyright Dates

Every year, the copyright dates should be updated. Here is an example bash script that can be used for that purpose.


#!/bin/bash

update_copyrights()
{

   if [ -z $1 ] || [ ! -d $1 ]; then
      echo
      echo "Error: update_copyrights expects valid directory, got $1"
      echo
      exit 1;
   fi

   cd $1

   for file in `ls`; do

      if [ -d $file ]; then
         echo "Traversing $PWD/$file"
         update_copyrights $file
         cd ..
      else
         echo "   Updating $file"
         `sed -i "s/\(copyright .*\)-$last_year/\1-$this_year/i" $file`
      fi

   done

}

if [ -z $1 ] || [ ! -d $1 ]; then
   echo
   echo "Usage: $0 [directory]"
else
   this_year=`date +%Y`
   last_year=$((this_year - 1))
   echo
   echo "Updating Copyrights from $last_year to $this_year"
   echo
   update_copyrights $1
fi

echo
echo "Done"
echo

Next Previous Contents