Developers of Sympa

[David Verdin <address@concealed>]

Dear Sympa developers,

**
This is a pretty long mail that aims to present you how we handled the maintenance of several versions of Sympa, the problems we met and the new functioning we adopted. We also ask for recommendations or "best practices" from your own experience to help us improve our version management.
**

In the Sympa project, we always have two versions of the code:
  - the stable version, corresponding to the current stable release; this code is modified to include bug fixes only;
  - the development version, in which are introduced bug fixes and all the new developments and contributions.

Problems

We had several problems regarding this organization.

1. Delay between bug fixes and new version

When a bug is fixed in the stable version, we commit the stable code to a repository corresponding to the branch of the stable release.
For example, if the stable release is 5.3, we commit the code to the "branches/sympa-5.3-branch" repository on our SVN server. and that's all. That means that people who install Sympa using an SVN export will have a Sympa with that bug fixed. However, people using the tar.gz file will still have this bug. Due to the time it takes to build a new tar.gz, we don't release one often. For example, the 5.3 release only had five versions (5.3, 5.3.1, 5.3.2, 5.3.3 and 5.3.4) each one with its own tar.gz file.

2. Concurrence between stable and development translations

The Sympa translations are hosted by internationalization catalogues (also called po files). We have only one version of these files per language, shared by all maintained Sympa version, because it would be unrealistic to maintain one for each version.
For a given version (being a stable or development version) the character strings to translate are derived from the source code. It contains tagged character strings that are used to build po files.
Basically, prior to create a new tar.gz file, the following actions are performed:
  1- the latest translations are brought from the translations server under the form of po files.
  2- the strings to translate are extracted to a file called sympa.pot, which will be a template to re-build po files.
  3- sympa.pot and po files are compared. New character strings are added to the po files; the character string that are no longer used are removed from the po files.
  4- updated po files are sent back to the translation server, the new strings ready for translations, the old strings removed.

The problem is as follows: as we maintain two different versions of Sympa, it is likely that the translations will diverge along the time, causing translation work loss.
Example:
- Version 5.3 uses the character string "Send love letter". So this string appears in its internationalization catalogues. Yvon, briton translator, translated it, so that briton-speaking people can send love it in their own language.
- While working on version 5.4b.3, Joe, who just broke up with his girlfriend, removes the "send love letter" option. He then releases the 5.4b.3 version of Sympa. In this process, he installs the updated translations into the translation server. Which means that the "Send love letter" character string disappeared from the translations *for all versions of Sympa*.
- Later, Jack fixes a bug in Sympa 5.3. He issues version 5.3.1, reintroducing the "Send love letter" character string, but without its translation, as it was lost during previous step.
- Yvon logs in to the translation server, discovers that his translation of "send love letters" disappeared, and swears that he will never ever again do any translation for Sympa.

Solutions

Translation problem: We modified the script that generates po files. This is how it works now:

  1- the latest translations are brought from the translations server under the form of po files.
  2- the strings to translate are extracted to sympa.pot
  3a- the latest po files are saved into a tmp directory.
  3b- po files are updated according to the renewed sympa.pot file.
  3c- the po files saved in tmp and the updated po files are merged. This way, all the strings lost in the new version of Sympa are reintroduced in the po files.
  4- updated po files are sent back to the translation server, the new strings ready for translations, the old strings stil there!

This can settle another problem: Strings never disappear! We could still have in version 7.2 some strings that were used for the last time in version 5.4.
To avoid it, each time we release a major version (e.g. 5.4), we will remove all strings that were exclusive of the previous version. Indeed, when we release a new version, we stop maintaining the code of the previous one, except for critical problems.

Version releases problem. We created two scripts that automate the operations necessary to release a new version.

One of the scripts, tag-development-version.pl, is used when creating a new version from the development trunk. This happens both when issuing a new unstable version of Sympa (e.g. 5.3b.4) or for the first release of the stable Sympa (e.g. 5.4).
This script will be used when we want to test a newly introduce feature, or when our beta version is good enough to be switched to stable version.

The other script, update-stable-version.pl, compares the stable SVN branch with the latest stable Sympa version and, if changes happened, creates a new stable version. It increases automatically the version number (i.e. switches from 5.4.1 to 5.4.2 automatically).
We intended first to run it daily, so that any bug fix could be included as fast as possible in the download file. However, we fear that it could produces very high version numbers (5.4.100 after fixing the 100th bug) and could confuse our users.

So?

We feel that we improved the way versions are handled. We would sure appreciate any input about the intended behaviour (applicable starting version 5.4).

Regards,

--

David Verdin
Comité réseau des universités