Introduction

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

Note it's recommended to compile KMess in a slackware 10.0 buildroot. It doesn't have to be a compile system, just enough files to compile.

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; also offering a quick direct link to download the latest kmess.pot file like this.
  5. Add translations as they come :)

Before branching

Files to update

  1. Files which need to be updated:
    • ChangeLog
    • NEWS
    • FEATURES
    • AUTHORS (for translations)
  2. Make sure the authors, contributors and translator names are up to date in:
    • the about dialog (main.cpp).
    • the docbook manual
    • the website's people page
  3. Set <UI version="3.1" ..> in *.ui files. check using: 
    find . -name *.ui | xargs grep 'version='
  4. If the default build type is set in the main CMakeLists.txt, comment it out, to default to a release build.
  5. Run includemocs

Testing the application

  1. Create an new user account to start with an 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.
      • 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, both for the manual and website later on.
  8. Make sure the code compiles against KDE 3.2 (e.g. using Slackware 10.0).
  9. Add release tagline to:
    • ChangeLog
    • NEWS

Branching

  1. create a branch for the release 
    ver="1.5"
svn copy http://kmess.svn.sourceforge.net/svnroot/kmess/trunk/kmess http://kmess.svn.sourceforge.net/svnroot/kmess/branches/kmess/kmess-$ver.x
  2. Update version in:
    • configure.in.in
    • Doxyfile
    • kmess.spec
    • kmess.lsm
    • autopackage/default.apspec
    • cmake/config-kmess.h.in

Releasing

Building the tarball

  1. Checkout SVN in a fresh directory: 
    ver="1.5"
mkdir kmess-$ver
svn checkout http://kmess.svn.sourceforge.net/svnroot/kmess/branches/kmess/kmess-$ver.x kmess-$ver
  2. Create or update the configure script: This also updates version from configure.in.in. 
    cd kmess-$ver/
make -f Makefile.dist
  3. Remove autom4te.cache. 
    rm -Rf autom4te.cache
chown -R root:root .
  4. Create the tarball. 
    cd ..
rm -f kmess-$ver.tar.gz
tar zcvf kmess-$ver.tar.gz --exclude=.svn kmess-$ver/
  5. Verify whether it compiles with KDE 3.2. This can be done in Slackware 10.0, using: 
    rpmbuild -tb kmess-$ver.tar.gz
    When it doesn't work, commit fixes to SVN and start over. This avoids releasing the wrong code.
  6. Build the autopackage: 
    cd kmess-$ver/
makeinstaller
make clean
cd ..
  7. Create the slackware package for klik:// 
    rpmbuild -tb "kmess-$ver.tar.gz"
  8. Port all fixes in the branch over to trunk.
  9. Finally tag the version in SVN: 
    svn copy http://kmess.svn.sourceforge.net/svnroot/kmess/branches/kmess/kmess-$ver.x http://kmess.svn.sourceforge.net/svnroot/kmess/tags/kmess/kmess-$ver

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
    • The slackware 10.0 package for klik://
  3. Add them to the file releases in the admin panel.
    • The "ChangeLog" entry should contains 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. See if the new download links are correct.
  4. Update the screenshots
    • Move the old screenshots to a new plain page.
    • Update the screenshots in the visual guide.
  5. Make sure the Changelogs appear (should happen by make parsing the latest NEWS file)
  6. Update the homepage text, move old releases to the archive.
  7. 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