Translate Toolkit & Pootle

Tools to help you make your software local

User Tools

Release Planning

This applies to all our tools but most specifically to Translate Toolkit, Pootle and Virtaal. As it is written here is applies mostly to Pootle but is applicable to other tools.


  1. Make sure users benefit from code improvements earlier rather than later
  2. Prevent code hanging around in our repositories
  3. Don't break things for users or administrators
  4. Reduce our effort required to release


What we are trying to avoid

These are things we've experienced in the past and we'd like to avoid them. We have had good fixes committed to products, but we don't release. We then forget that most of our users aren't using master and they don't benefit. We avoid releasing because it is disruptive for users and it is time consuming for us to make a release.

The cost of releasing

Each release has the following costs in terms of our time:

  1. Prepare the source
  2. Release messages, notifications and updates of site info
  3. Testing the tarball
  4. Code to manage migration of data between versions

Packagers' time

  1. Repackaging
  2. Implementing dependency changes
  3. (maybe) packaging new dependencies

Admins' time

  1. Reading the release notes
  2. Planning for migration
  3. Migration
  4. Server downtime

Users' time

  1. Learning how new or changed things work

Time based releases


  • Can synchronise to align with dependencies
  • We plan to release code and know it will be released


  • Features need to align with the time based release cycle
  • Driven by the calendar and not sense

The situation as related to Pootle 2.1 and 2.2

2.1 is stable and reliable, widely deployed and dependable.

2.2 has a major UI refresh and a very different way of doing things. It seems to be widely deployed and we assume thus tested, but most Pootle devs have not deployed this version widely.

The Plan

  1. Align with Django releases - matching Django means that we stay aligned with our core platform.
    1. Need to set a policy regarding the minimum required Django version (can't be supporting 1.0 forever). --- Julen Ruiz Aizpuru 2012/03/28 20:36
  2. Release every 6 months for trunk (Currently 2.2, 2.3, 2.4, etc) - far enough apart to allow code to get committed. Far enough to not be releasing every week.
  3. Bugfix for 18 months on stable (Currently 2.1) - long enough to allow users a stable ride. Backporting of non-invasive features, bugfixes and security fixes are done on this branch.
  4. Staging server for all active branches - anyone should be able to experiment on the staging server for any active branch. That would be 2.1 and 2.2 currently.
  5. Major changes and diversions from the time based releases are managed in branches - code for a specific client or situation is branched and can safely ignore the time based cycle. The changes should be merged as soon as the next available release cycle starts.

Timing of things

  1. Start: 0 month
  2. Schema changes: 0-2 month - these should happen within the first 2 months of a cycle to allow them to be stabilised and evaluated and to allow migration scripts to be widely tested.
    1. This means features that change/add models need to be implemented at this stage so they need to be decided for month 0. --- Julen Ruiz Aizpuru 2012/03/28 20:45
  3. Normal development: 2-5 months
  4. Stabilisation: 6 month
  5. String freezes: 6 month - translation can happen at any time. But strings are not to be broken in the last month.
  6. Release

Packagers must be aware of the timing in order to properly implement any required changes.

Support for saving time and preventing disasters

We need to reduce the time and effort of a release considerably but at the same time prevent disasters.

Things that we could implement are:

Saving time in release

  • Automation of the release steps.
    • tarball creation and checking
    • file uploads
    • notifications to distribution services: freecode, pip, etc
  • Automate release planning. Catch string changes in month 6 and schema changes after the first two months and flag them as broken builds.
  • One place for all texts
    • Texts descriptions of tools are repeated: pip, packages, etc. Working from one place helps reduce the effort of maintaining that text.
    • Various tools need classification data: tags, languages, licenses. A central list of these could then be used in ./ and other places.

Preventing disasters

  • Staging server makes Pootle always available and allow errors to be reported and catches any errors that prevent booting
  • Migration testing. This is probably the biggest deployment risk. We need to automate tests of this process across the builds we care about and with data that reflects reality.
  • Selenium to test user interaction with Pootle
  • Automated build processes catch the errors early in the code cycle