Releasing a new version

We try here to summarize what we need to do to publish a new release. We are rapidly recalling the release cycle then listing the different tasks to be done before publishing a new release.

The release cycle

We have chosen a 3 month release cycle:

• month 1 → development
• month 2 → test and documentation update, new release at end of month
• month 3 → communication

The translation and graphic work is not mentioned in this cycle because translations can start at any moment and because graphic design has just started. However the ongoing translation and graphic work should also try to be ready by the end of month 2 in order to be included in the release to be published.

Please note that building and uploading CD’s to our website now takes around 3-4 days, which means that the release must be ready several days before the release date. For this reason tests will first be conducted on a reduced set of CD’s in order to reduce the time required to upload new CD builds.

Development process

The development effort is guided by our road map. We should try to do only what is on this list but of course tasks may be added, removed or postponed on the flow depending on the needs or the issues. Note that a road map for graphic designers should also be setup in a near future.

Testing process

New builds will be uploaded during the test month on the dailybuild section (http://download.doudoulinux.org/dai...). The team and project contributors are asked to download and test them. Please fill bug reports on our bug manager whenever needed. Don’t forget to check before if a related bug doesn’t already exist :).

Testing ISO/IMG files

ISO and USB image files must be checked for their SHA1 sum on the server before moving them to the official download section. The commands are the following:

cd public_html/
cd download/dailybuild/livecd/
sed -i 's|isocd/||' *.sha1
sha1sum -c *.sha1
[…]
cd ../liveusb/
sed -i 's|usbimg/||' *.sha1
sha1sum -c *.sha1
[…]
cd ../../download/incubator/
sed -i 's|isocd/||' *.sha1
sha1sum -c *.sha1
[…]

Each file should return OK, otherwise the SHA1 file is first to be compared with the local one, then the local ISO/IMG file SHA1 is to be checked and finally the file can be uploaded again.

Mirrors and torrents

Once the images are on the main server and validated, the most downloaded languages must be copied onto the mirrors using an FTP client. Currently images are transfered onto mirrors in less than 2 minutes each (this is likely the same datacenter).

Torrent files can now be built from the main server, no need to download images to compute their hash series. The script is located into the torrents directory.

Documentation

We are listing here the pages needing to be written or modified.

• If new tools are added to the release, new web pages describing these tools should be added and translated. Some other pages may also need updating for example to add some words about these new tools, but this should only be done just before the release is out (because we still do not have a work copy of our documentation).
• If existing tools have been changed, the documentation page must be changed in each available language.
• Some pages and their translations may require updating
  • the page Release notes
  • the page What’s new in the latest release?
  • the page Download
  • the page Tips and tricks
  • the page Frequently asked questions
  • the page Known issues
  • the page Where goes DoudouLinux?
  • the page Template promotion article
  • all the pages of translation status (Transifex images + global status table)
• The PDF documentation must be recompiled and uploaded.

Website

Several tasks are needed to welcome our new release on our website:

• A new banner should be prepared to announced the availability of the new release.
• Update the banner texts!
• The home page and the download page should be updated in each language.
• Write news to announce the new release in each language. It is certainly a good idea to publish news as soon as website pages are modified for the new release in order to warn about the fact that documentation may not reflect the downloadable release until the next one is published.
• Update our Debian package repository with new package builds.

Project on Gna

Finally on our project manager small actions are required too:

• Remove tickets that are closed.
• We have to create new labels to let people tag tickets with the new release number.
• Create a tag on SVN to mark the new release in the file history.