Introduction

This page summarizes the policies we currently follow througout KMess. It's meant to give some background about "how we did things so far", and these are not meant as strict rules. If anything is missing at this page, please add it. If you disagree with something, we love to know it as well.

Coding policies

Coding standards

See coding standards ;)

Displaying error messages

Currently there is a distinction between certain error messages which should be visible, and which ones should not.

As rule of thumb, normal errors (e.g. connection lost, file transfer failed) are always shown to the user. Some error messages (e.g. connected elsewhere) are shown in a passive dialog box to avoid interrupting the user.

Protocol errors are not shown in the interface at all. For example:

  • if an emoticon failed, the user already sees this because the grey placeholder box will never be rendered.
  • if a picture transfer failed, you simply still see the old picture.

Spawning message boxes with "There was an unsupported protocol command" is not helpful for the user anyways. They can't help it, nor fix it.

However, the precise error message will always be shown with a kWarning() at the console. This allows poweruses to find out what's happening.

Also see: debugging practices.

Dealing with unsupported chat messages

If a protocol message is not supported, we generally log it with kWarning().

If a client uses a feature in the chat we don't support yet, we make sure there is a red warning message for it. for example:

  • The contact is inviting you for 'Tic-Tac-Toe', but this is not implemented yet.

While playing Tic-Tac-Toe might not be that challenging, it would be unfortunate if you missed parts of a conversation without being aware of it. That's why we spent effort on KMess 1.5 with "receiving" stuff. Make sure everything someone can send you is either received (e.g. emoticons, offline-im, winks), or an error message is displayed in the case of activities and games.

Some features like voiceclips support are mentioned in the 'clientcaps' field, so the sending party will automatically get a notice if the receiver can't see the given message.

Debugging practises

See debugging practises ;)

Project management

Tickets

See tickets usage for our vision on dealing with tickets.

Translations

At some point in the development process (typically after a beta, or just before) it's time to start a "string freeze". This allows translators to update the translations without worrying about constant changes to the translations.

Off course, everyone is invited to submit translations throughout the whole development cycle, as it helps to keep the translation more recent.

Releases

See file releases for a guide to make a release. Packagers, please look at packing notes as well.

Version numbers

So far we've used the following numbering scheme:

  • the major number changes with big changes. (1.x -> 2.x was the change to KDE 4)
  • the minor number changes with new features (1.4 -> 1.5, 2.0 -> 2.1 all have new features)

If there are serious bugs in a given release, a new revision (e.g. 1.5.1, 1.5.2) can be released. These releases only contain backports of bugfixes, and no new releases.

Version labels

  • "pre" means a preview release. For some reason it was time to get something out (e.g. too much time between a release).
  • "alpha" is used since 2.0 to mark a preview. An alpha release can be pretty stable, but new features will still be added.
  • "beta" is used when no new features will be added. There is only bugfixing to get the release out.
  • "rc" is release candicate. If everything is OK, we can just flip version numbers and release the same code as-is.

While alpha is generally equivalent for "unstable" we still tried to make 2.0-alpha pretty stable. It gives a good impression, and people can actually use the application to test it. ;-) Consider "alpha" to be an other name for "we will still add features".

When to release

So far we haven't been working with time-based releases, but feature-based releases. A new version is released when everything is done and bugfree.

SVN branches

The following SVN branches are used:

  • /trunk/kmess/ - contains the latest code.
  • /branches/kmess/ - folder for special changes (e.g. porting to KDE 4)
  • /branches/kmess/kmess-1.5.x/ - the latest 1.5 code, used to be open for backports.
  • /tags/kmess/ - contains the released code, and will not change.
  • /tags/kmess/kmess-1.5.0/ - the released 1.5.0 code
  • /tags/kmess/kmess-1.5.1/ - the released 1.5.1 code
  • /tags/kmess/kmess-1.5.2/ - the released 1.5.2 version

So when a normal release is made (e.g. 1.5) the following happens:

  • /trunk/kmess is branched to /branches/kmess/kmess-#.#.x
  • when the branch is ready to release, /branches/kmess/kmess-#.#.x is tagged with the version number.
  • the branch remains open for backports.
  • all fixes are also backported to trunk in the meantime.
  • trunk is already open again for the next version.

If there are serious issues in a given release, the following happens:

  • the feature is backported to the branch
  • with enough bugs fixed, the branch is tagged

For example, /branches/kmess/1.5.x got tagged as /tags/kmess/kmess-1.5.0 initially. After some fixes it got tagged as /tags/kmess/kmess-1.5.1.

The .x is added to the branch name on purpose because it's harder to explain that "1.5" and "1.5.0" mean something different.