SquirrelMail  
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

  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 in three places:
    1. Variables in functions/strings.php ($version = '1.4.20', $SQM_INTERNAL_VERSION=array(1,4,20)).
    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 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 (NOTE: currently, upload functionality is disabled; upload instructions are below). 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: 
      gpg -a --detach-sign --output squirrelmail-webmail-X.Y.Z.tar.gz.sig squirrelmail-webmail-X.Y.Z.tar.gz
gpg -a --detach-sign --output squirrelmail-webmail-X.Y.Z.tar.bz2.sig squirrelmail-webmail-X.Y.Z.tar.bz2
gpg -a --detach-sign --output squirrelmail-webmail-X.Y.Z.zip.sig squirrelmail-webmail-X.Y.Z.zip
      An example for how to verify that your signature worked would be:
      gpg --verify squirrelmail-webmail-X.Y.Z.tar.gz.sig squirrelmail-webmail-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.22 was uploaded in July, 2011.
      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/projects/squirrelmail/files/
        For example, click to navigate into the "stable" directory and then click on the "Add Folder" button, 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): 
        cd squirrelmail-webmail-1.4.20-release_work_area
sftp [email protected]
        Once logged in, here are the needed sftp commands: 
        cd /home/frs/project/s/sq/squirrelmail/stable/1.4.20
put squirrelmail-webmail-1.4.22.tar.bz2
put squirrelmail-webmail-1.4.22.tar.bz2.sig
put squirrelmail-webmail-1.4.22.tar.gz
put squirrelmail-webmail-1.4.22.tar.gz.sig
put squirrelmail-webmail-1.4.22.zip
put squirrelmail-webmail-1.4.22.zip.sig
put squirrelmail-webmail-1.4.22/doc/ReleaseNotes
      3. Now you have to use the web interface to assign properties to the uploaded files:
        https://sourceforge.net/projects/squirrelmail/files/stable/1.4.20/
        1. Click on the "i" icon next to the ReleaseNotes file and change the file name to "README" and click "Save". SourceForge no longer requires you to associate release notes with your files - it does it automatically based on file name ("README").
        2. Click on the "i" icon next to the .tar.gz file and click the "Select all" link and then the "Save" button to make the .tar.gz file the default download for all visitors.
      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)
  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 one 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.
  7. 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.
    6. You can now safely delete the squirrelmail-webmail-1.4.20-release_work_area directory that was created by the make-release-webmail script.
  8. 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) (View news posts here: https://sourceforge.net/news/?group_id=311)
      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: [email protected], [email protected], [email protected], [email protected], [email protected]
      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

  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. 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 in three places (this should just involve removing " [SVN]" from each):
    1. include/common.h: 
      #define IMAP_PROXY_VERSION      "1.2.8"
    2. imapproxy.spec: 
      %define ver    1.2.8
    3. pkginfo: 
      VERSION=1.2.8
  5. SVN packaging:
    1. Commit final changes to Subversion (include/common.h, imapproxy.spec, pkginfo)
    2. 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
    3. 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.
    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-imap_proxy-X.Y.Z.tar.gz.sig squirrelmail-imap_proxy-X.Y.Z.tar.gz
      2. gpg -a --detach-sign --output squirrelmail-imap_proxy-X.Y.Z.tar.bz2.sig squirrelmail-imap_proxy-X.Y.Z.tar.bz2
      3. gpg -a --detach-sign --output squirrelmail-imap_proxy-X.Y.Z.zip.sig squirrelmail-imap_proxy-X.Y.Z.zip
      An example for how to verify that your signature worked would be:
      1. gpg --verify squirrelmail-imap_proxy-X.Y.Z.tar.gz.sig squirrelmail-imap_proxy-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-imap-proxy 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.2.7 was uploaded in August, 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 "imap_proxy" directory and then click on the "gear" icon next to the "imap_proxy" directory and select to create a new folder, naming it with the release version (e.g., 1.2.8).
      2. Now, you can sftp to the release directory (this assumes you are in the (local) directory where you ran the make-release-imap-proxy script):
        sftp [email protected]
        Once logged in, here are the needed sftp commands: 
        cd /home/frs/project/s/sq/squirrelmail/imap_proxy/1.2.8
put squirrelmail-imap_proxy-1.2.8-release_work_area/squirrelmail-imap_proxy-1.2.8.tar.bz2
put squirrelmail-imap_proxy-1.2.8-release_work_area/squirrelmail-imap_proxy-1.2.8.tar.bz2.sig
put squirrelmail-imap_proxy-1.2.8-release_work_area/squirrelmail-imap_proxy-1.2.8.tar.gz
put squirrelmail-imap_proxy-1.2.8-release_work_area/squirrelmail-imap_proxy-1.2.8.tar.gz.sig
put squirrelmail-imap_proxy-1.2.8-release_work_area/squirrelmail-imap_proxy-1.2.8.zip
put squirrelmail-imap_proxy-1.2.8-release_work_area/squirrelmail-imap_proxy-1.2.8.zip.sig
      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., imap_proxy ==> 1.2.8).
        2. 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.
      4. Go to the latest STABLE WEBMAIL release package (e.g., navigate the file manager to stable --> 1.4.21 and click to edit the properties of the .bz2 file therein. Make sure it is set as the default download for all platforms. This ensures that SourceForge sees this as the "newest" release file, that which will be featured on our SourceForge summary page (see next step).
      5. Verify that SourceForge has *NOT* automatically chosen to display the new release as the official release on the main SquirrelMail project page (it will be too confusing to users who expect the webmail product to be the main download file):
        https://sourceforge.net/projects/squirrelmail/
  6. Defrosting: Prepare SVN for continued development
    1. Go back to your regular SVN development directory.
    2. Update the version number strings in three places by incrementing the incremental release number by one and adding " [SVN]" after it
      1. include/common.h: 
        #define IMAP_PROXY_VERSION      "1.2.9 [SVN]"
      2. imapproxy.spec: 
        %define ver    1.2.9 [SVN]
      3. pkginfo: 
        VERSION=1.2.9 [SVN]
    3. Commit these changes to SVN with a note saying that it is ready for continued development.
  7. 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 $imap_proxy_version and $imap_proxy_svn).
    4. Upload the md5 checksums and sha1 checksums that make-release-webmail calculated and your GPG signatures into the sums/ dir.
  8. Blatant yelling: Announce the release to the World.
    1. FIXME/TODO.....

5.3 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.

5.4 Updating Copyright Dates

Every year, the copyright dates should be updated. This action should be taken against most of the repository:

  1. STABLE (svnroot/squirrelmail/branches/SM-1_4-STABLE/squirrelmail)
  2. DEVEL (svnroot/squirrelmail/trunk/squirrelmail)
  3. IMAP Proxy (svnroot/squirrelmail/trunk/imap_proxy)
  4. DOCUMENTATION (svnroot/squirrelmail/trunk/documentation)
  5. DECODE (svnroot/squirrelmail/trunk/decode)
  6. UTIL (svnroot/squirrelmail/trunk/util)
  7. LOCALES (svnroot/squirrelmail/trunk/locales)
Also, make sure to update the define statement in trunk/squirrelmail/include/constants.php around line 28 that defines SM_COPYRIGHT.

A script that can be used to update any of the paths that are listed above (you have to run it against each one) is stored in svnroot/squirrelmail/trunk/util/update-copyright.

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