Release Management

Revision as of 14:38, 11 June 2010 by Cwickert (talk | contribs) (Dependencies: formating)
Jump to: navigation, search

In order to maintain stability and compatibility all releases must follow a clearly defined release process. This helps us to maintain quality of the LXDE components and avoids erroneous releases that cause problems for LXDE's users. Please support the LXDE release engineering by testing the source code of components, filing bugs and coding on LXDE.


The release team currently consists of a number of continuous contributors and package maintainers of distributions offering LXDE including:

  • Andrew Lee (Debian)
  • Andrea (OpenSuse)
  • brother (Translation coordinator)
  • Christoph Wickert (Fedora)
  • PCMan (Core Developer)
  • Marty Jack (Core Developer)
  • Please complete the list


Release criteria

  • Releases must cleanly compile into binaries.
  • Releases must not break dependencies.
    • If a release introduces incompatible changes (ABI, API or configuration), its dependencies must be updated and released as well.
  • Developers should indicate incompatible API changes in a library such as libfm or menu-cache should be indicated through a change of the SO name.
  • Releases must be able to install cleanly


  1. When a developer is about to release a new version of a component, he sends out an announcement to the lxde mailing list
  2. The release manager takes a quick look at the code and confirms that it fulfills the release criteria and is ready for testing.
    1. The release manager sends out a call for testing to the mailing list and freezes the code. Only bugfixes are allowed to go in.
  3. The translation coordinator checks the strings for obvious spelling mistakes and consistency.
    1. The translation coordinator sends out a call for translations to the LXDE translation list and announces a string freeze. New strings must not be added without permission of the translation coordinator.
  4. Package maintainers test the code. If they like, they do a test release in the development branch of their distribution, e.g. Debian Experimental or Fedora Rawhide. Errors should be reported on the mailing list and/or in the bug tracker. If everything works as expected, this should be reported on the mailing list.
  5. The release manager should watch the bugtracker for new bug reports and coordinate the fixes with the developers.
  6. The translation coordinator takes care of translation process.
  7. After one week of testing the release manager and the translation coordinator decide whether the new release can be published based on the feedback from the mailing list, the number of bugs in the bugtracker and the status of the translations.
    1. If there are known bugs, the release manager will encourage the developers to fix them.
    2. If translations are incomplete, the translation coordinator sends out a nag mail to the translation mailing list and/or the translators directly.
  8. If everything is fine the release manager tags the code in git and releases a tarball.
  9. The release is announced on the mailing list and in the blog.
  10. The freeze is lifted.

based on proposal at the LXDE developer mailing list.


LXDE aims at keeping the dependencies between components low. Nevertheless speed and the usage of low resources are other priorities of the LXDE project. Sometimes there are components dependent on each other.

The following components are known to impact others:

  • menu-cache: libfm, lxpanel, lxlauncher
  • libfm: pcmanfm
  • lxsession: lxappearance, lxinput
  • lxsession: lxsession-edit
  • lxmenu-data: lxlauncher, lxpanel
  • pcmanfm: lxde-common (configuration only)
  • lxpanel: lxde-common (configuration only)
  • openbox: lxde-common (configuration only)


To gather people and resources and enable better communication we have set up the some communication channels:

  1. A Dev Mailinglist for the LXDE Project used by the release team
  2. Please join us also in the LXDE contributors channel at #lxde