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
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.
Update the ReleaseNotes, keeping the same general format.
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:
Variables in functions/strings.php ($version = '1.2.1', $SQM_INTERNAL_VERSION=array(1,2,1)).
doc/ChangeLog
doc/ReleaseNotes
SVN packaging:
Commit final changes to Subversion (doc/ChangeLog, doc/ReleaseNotes, functions/strings.php)
Tag SVN with the release number in the format rel-X_Y_Z (rel-1_2_1). Example:
Use the script make-releasefound 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.
Create a GPG signature for each of the newly created release packages. Typically, this can be done with:
gpg -a --detach-sign --output squirrelmail-X.Y.Z.tar.gz.sig squirrelmail-X.Y.Z.tar.gz
gpg -a --detach-sign --output squirrelmail-X.Y.Z.tar.bz2.sig squirrelmail-X.Y.Z.tar.bz2
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:
(huh: don't go to sleep before you're finished making the release)
Defrosting: Prepare SVN for continued development
Go back to your regular SVN development directory.
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]';).
Add a new section in doc/ChangeLog for the new release, followed by ' - SVN'
Archive the doc/ReleaseNotes for this release like this:
Commit all these changes to SVN with a note saying that it is ready for continued development.
sf.net admin stuff: Post the release files on SourceForge (you need to be a "release technician" to do this)
Create the new release of files
Log into SourceForge and go to the SquirrelMail project page.
Under the "Project Admin" menu, select "Feature Settings".
Now click the "Manage" link to the right of "File Release System".
Click "Add Release" for the correct package.
Enter the release name in X.Y.Z format (no SquirrelMail or anything, just X.Y.Z) and click the "Create This Release" button.
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.
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.
Add the newly uploaded files to the release
Go down to the "add files to this release" section
Select the files you recently uploaded (be nice and leave other peoples files alone).
Click the "Add Files and/or Refresh View" button.
For each files added (tar.gz, tar.bz2, and zip), one at a time, set the file info correctly.
Set the processor to 'Platform-Independent'.
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).
Click the "Update/Refresh" button for that file.
Annouce the file release to those monitoring it with the button on the bottom of the page.
Enable downloading: Update the download page for the SquirrelMail website.
SSH into sciurida
Change to the web directory for SquirrelMail (currently /srv/www/www/htdocs).
Edit download.php and change the version number as necessary. This is a php variable in the top part of the file.
Edit plugin_query.php file and change version number. This file informs pupdate plugin users about new release.
Upload the md5 checksums and sha1 checksums that make-release calculated and your GPG signatures into the sums/ dir.
Blatant yelling: Announce the release to the World.
Post the release to the SourceForge news system. (you need to be a "forum moderator" to do this)
Log into SourceForge.net and proceed to the SquirrelMail project page.
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).
Submit the news, go preview it, and fix it if you did something silly. :)
Send a message to squirrelmail-announce telling people about the release.
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
Again, use your brief 3 to 8 line message
The subject should read "ANNOUNCE: SquirrelMail X.Y.Z Released"
Validate the translation: Before beginning, there are several things
that need to be verified for the translation to be acceptable:
Copyright: Make sure it's OK to assign the copyright to the
SquirrelMail Project. We won't accept translations with other
copyright holders.
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.
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.
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.
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").
Sanity check: Have a look over the translation file(s) and make
sure they look reasonable.
sec_remove image: Ask for a translated copy of the
sec_remove_eng.png image file (renamed, of course, to
sec_remove_<language>.png).
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"
