SquirrelMail  
Donations
News
About
Support
Screen shots
Download
Plugins
Documentation
Sponsors
Bounties



SquirrelMail Developer's Manual: Project Administration Next Previous Contents

5. Project Administration

5.1 Release Instructions

  1. 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).
  2. Usual sanity: Check the code over to make sure we are absolutely ready.
  3. 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.
  4. Gearing up: Update the version number strings at 3 places:
    1. Variables in functions/strings.php ($version = '1.2.1', $SQM_INTERNAL_VERSION=array(1,2,1)).
    2. doc/ChangeLog
    3. doc/ReleaseNotes
  5. 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 rel-X_Y_Z (rel-1_2_1). Example:
      svn copy https://squirrelmail.svn.sourceforge.net/svnroot/squirrelmail/branches/SM-1_4-STABLE/squirrelmail \
      https://squirrelmail.svn.sourceforge.net/svnroot/squirrelmail/tags/rel-1_2_1
      
    3. Use the script make-release 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 sf.net instructions or see sf.net upload protocols.
    6. (huh: don't go to sleep before you're finished making the release)
  6. 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.2.2 [SVN]';).
    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.
  7. sf.net admin stuff: Post the release files on SourceForge (you need to be a "release technician" to do this)
    1. Create the new release of files
      1. Log into SourceForge and go to the SquirrelMail project page.
      2. Under the "Project Admin" menu, select "Feature Settings".
      3. Now click the "Manage" link to the right of "File Release System".
      4. Click "Add Release" for the correct package.
      5. Enter the release name in X.Y.Z format (no SquirrelMail or anything, just X.Y.Z) and click the "Create This Release" button.
      6. The next page it shows you will be the same page you get to if you clicked on "edit release" from the "Edit/Release Files" page earlier and selected a release name.
    2. Enter the ChangeLog (only the part of that file for this release, not the whole file) and ReleaseNotes (the whole file) for this SourceForge file release.
    3. Add the newly uploaded files to the release
      1. Go down to the "add files to this release" section
      2. Select the files you recently uploaded (be nice and leave other peoples files alone).
      3. Click the "Add Files and/or Refresh View" button.
    4. For each files added (tar.gz, tar.bz2, and zip), one at a time, set the file info correctly.
      1. Set the processor to 'Platform-Independent'.
      2. Set the file type (.bz2 for the tar.bz2 file, .gz for the tar.gz file, .zip for the zip file, and .rpm for the .rpm files).
      3. Click the "Update/Refresh" button for that file.
    5. Annouce the file release to those monitoring it with the button on the bottom of the page.
  8. 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. This is a php variable in the top part of the file.
    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 calculated and your GPG signatures into the sums/ dir.
  9. 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 Adding New Languages

  1. 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.
  2. 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.
  3. Update ChangeLog.locales: Make a note of the new addition
  4. 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.
  5. 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.
  6. sec_remove image: The translated sec_remove image file should be placed in the main locales images directory.
  7. 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"
  8. Update SquirrelMail manual: Update the supported languages list in the Developer's Manual ( "Supported Languages" in docs/devel/devel-3).
  9. Add translator(s): Add the translation maintainer(s) to the TRANSLATORS file.
  10. Update statistics: Add the translation team to the teamnames file.
  11. Changelog: Add the new translation to the Changelog for both STABLE and DEVEL.


Next Previous Contents
© 1999-2009 by The SquirrelMail Project Team