Introduction

This is a short summary for the steps to release a new version of KMess.

Some weeks before the release

  1. When the featureset for your release is done, and only bug-fixes are going to be done before releasing, enter string freeze.
  2. Update the kmess.pot file, with the SVN /po/ folder tools, maketrans/mergetrans.
  3. Look at the latest translators from SVN here and here to find out which translators have to be contacted.
  4. Send them a mail telling that the latest version is going to be released soon, and politely ask them if they can contribute again by translating the app; a nice extra is offering a quick direct link to download the latest kmess.pot file like this.
  5. Add translations as they come :)

Testing the application

Before a release can be done, make sure KMess passes all of the following tests:

  1. Create an new user account to start with a clean fresh ~/.kde folder.
  2. Test the contact list:
    • creating a group
    • creating a contact
    • moving a contact
    • copying a contact
    • removing a contact from a group
    • removing a contact completely
  3. Test P2P support with new clients.
    • Test receiving / sending of:
      • pictures
      • emoticons
      • files
    • Fake various situations:
      • sending a second file over the same direct connection (should re-use the DC).
      • sending two file invitations at the same time (should wait until the DC is up).
      • aborting a file transfer by the sender.
      • aborting a file transfer by the receiver.
      • have a slow DC invitation startup (should start file transfer after some timeout).
      • close the DC half-way the transfer (should continue over the SB).
      • let the DC fail to write a message (should resend it over the SB).
    • Check the logs for warnings.
    • Clients to test with:
      • Windows Live Messenger
      • MSN 7.5 (optional)
      • aMSN
      • Pidgin-IM
      • Kopete
      • Meebo
      • e-messenger
      • Mercury Messenger
      • emesene
  4. Test right-to-left support with chat styles: 
    cd kmess/styles
for i in */*.xsl; do name=`dirname $i`; xsltproc $i examplemessage.xml > $name/test.html; done
konqueror */test.html
  5. Test for memory leaks.
  6. Review the manual for missing items.
  7. Create screenshots, for both the manual and website's Screenshots page.
  8. Make sure the code compiles against your version's minimum requirements: e.g. for KMess 2.0, Qt 4.4.0 and KDE 4.1

Before branching

Files to update

  1. Files which need to be updated (remember to also update the version number):
    • ChangeLog
    • NEWS
    • FEATURES
    • Optionally, also the package creation descriptor files: kmess.spec, kmess.lsm, autopackage/default.apspec
  2. Add release tagline to:
    • ChangeLog
    • NEWS
  3. Make sure the authors, contributors and translator names are up to date in:
    • AUTHORS (for translations)
    • the about dialog (main.cpp).
    • the docbook manual
    • the website's people page
  4. Run includemocs

Branching

  1. create a branch for the release 
    ver="2.0"
svn copy https://kmess.svn.sourceforge.net/svnroot/kmess/trunk/kmess https://kmess.svn.sourceforge.net/svnroot/kmess/branches/kmess/kmess-$ver.x
  2. If the default build type is set in the main CMakeLists.txt, comment it out, to default to a release build.

Releasing

Building the tarball

  1. Checkout SVN in a fresh directory: 
    ver="2.0"
mkdir kmess-$ver
svn checkout https://kmess.svn.sourceforge.net/svnroot/kmess/branches/kmess/kmess-$ver.x kmess-$ver
  2. Change the ownership for the entire SVN copy to user root, group root, and the permissions for files and directories. 
    chown -R root:root .
find -type d -exec chmod 755 {} ;
find -type f -exec chmod 644 {} ;
  3. Again, make sure the code compiles against your version's minimum requirements. When it doesn't work, commit fixes to SVN and start over. This avoids releasing the wrong code.
  4. Port all fixes in the branch over to trunk.
  5. If the default build type is set in the main CMakeLists.txt, comment it out, to default to a release build.
  6. Tag the version in SVN: 
    svn copy https://kmess.svn.sourceforge.net/svnroot/kmess/branches/kmess/kmess-$ver.x https://kmess.svn.sourceforge.net/svnroot/kmess/tags/kmess/kmess-$ver
  7. Create the tarball. 
    cd ..
rm -f kmess-$ver.tar.gz
tar zcvf kmess-$ver.tar.gz --exclude=.svn kmess-$ver/
  8. Build the autopackage: 
    cd kmess-$ver/
makeinstaller
make clean
cd ..

Done!

Uploading

  1. Write a good announcement. Look at previous versions. Copy this in Kate (or some notepad), you'll need it many times to create each package with the file releases.
  2. FTP the files to upload.sourceforge.net
    • One source tarball
    • The autopackage installer
  3. Add them to the file releases in the Source Forge project admin panel.
    • The "ChangeLog" entry should contain the items of the NEWS file.
    • The description should contain the hand-written announcement.
    • Use the same package type + architecture as previous releases.

After the release

Updating the website

  1. Update ./resources/version.xml
  2. Run make
  3. Update the database (kmess_statistics) so that all download links link to the correct new files
  4. See if the new download links are correct.
  5. Update the screenshots
    • Move the old screenshots to a new plain page.
    • Update the screenshots in the visual guide.
  6. Make sure the Changelogs appear (should happen by make parsing the latest NEWS file)
  7. Update the homepage text, move old releases to the archive.
  8. Upload the contents 
    make
make upload

The announcement

  1. Update the sites:
  2. Post an announcement to kmess-devel () lists.sourceforge ! net. For a good example, see the attached example of Decibel.

Previous announcements

Attachments