diff --git a/livesupport/doc/index.html b/livesupport/doc/index.html index 95d4f438e..baf34fed2 100644 --- a/livesupport/doc/index.html +++ b/livesupport/doc/index.html @@ -13,7 +13,7 @@ Development Loan Fund, under the GNU GPL.

Scope

@@ -33,7 +33,8 @@ compile LiveSupport
  • LiveSupport development environment
  • UML model
    • -
  • installation instructions
    +
  • installation instructions
    • +
  • release process

    • Generated documentation

    diff --git a/livesupport/doc/release.html b/livesupport/doc/release.html new file mode 100644 index 000000000..eb9ea6f09 --- /dev/null +++ b/livesupport/doc/release.html @@ -0,0 +1,121 @@ + + + + + LiveSupport release process documentation + + + +

    Preface

    +This document is part of the LiveSupport +project, Copyright © 2004 Media +Development Loan Fund, under the GNU GPL.
    + +

    Scope

    +This document describes the process of releasing a new version of +LiveSupport. Obviously this document is only relevant to people who +have the rights and permissions to make such a release.
    +

    Introduction

    +For all the releases of LiveSupport to remain consistent, it is +preferable to have a repeatable release process, which will be followed +when creating releases. This ensures that no matter who creates the +releases, they will remain similar.
    +
    +The release process boils down to the following steps:
    + +

    Getting LiveSupport sources

    +It is assumed that the person doing the release has a read/write access +to the LiveSupport version control system. As a first step of the +release process, a fresh copy of the version control repository is +check out, so as to insure that:
    + +To get a fresh copy of the LiveSupport repository, execute the +following in an empty directory:
    +
    +
    cvs -z3 -d :ext:<username>:netfinity-5.mdlf.org:/home/cvs checkout livesupport
    +
    +Where <username> is the user name for accessing the +repository of the person making the release.
    +

    Checking the distribution script

    +It is advisable to check the installation script bin/dist.sh, +to make sure it refers to up-to-date information from the development +environment.
    +
    +The most important aspect to check is that the specific versions of +tools mentioned in the distribution script are in sync with the tools +compiled by the master Makefile under the target tools_setup. +To check this, compare tool version variables in the two files, e.g. BOOST_VERSION +from Makefile with boost_version from bin/dist.sh. +Make sure to check the versions for all the tools mentioned in these +files.
    +

    Creating release tarballs
    +

    +To create the release tarballs, invoke the distribution script bin/dist.sh, +with the release version as its single parameter:
    +
    +
    ./bin/dist.sh <ls-version>
    +
    +This will create two tarballs in the current directory:
    + +

    Testing the tarballs

    +Having broken releases is very annoying, thus it is highly recommended +that the release tarballs are tested on a plain vanilla system. To test +the tarballs, follow the procedure described in the LiveSupport installation document.
    +
    +Do not publish tarballs that have not been tested, or are known to be +broken.
    +

    Tagging the sources

    +After the tarballs have been tested, the release can be finalized. As a +first step, the current state of the LiveSupport version control +repository has to be tagged, so that the the very versions in the +release can be retrieved at any later date. To tag the repository, +issue the following command from the LiveSupport checked out source +directory:
    +
    +
    cvs tag livesupport_<ls-version>
    +
    +This will tag the current state of the repository with the tag livesupport_<ls-version>, +enabling later retrieval of this specific state.
    +

    Publishing the tarballs

    +To make the release available to the public, the created tarballs have +to be published. This is done by making the files accessible under the +URL http://ls-demo.campware.org/download/ , which can be +achieved by moving the files to the /var/www/download/ +directory on the ls-demo.campware.org system. It is +assumed that the person making the release has ssh access to this +system and write access to this directory. The files can be published +by executing the following command:
    +
    +
    scp livesupport-<ls-version>.tar.bz2 livesupport-libraries-<ls-version>.tar.bz <username>@ls-demo.campware.org:/var/www/download
    +
    +

    Announcing the release

    +For the public to be aware of the new release, it has to be announced. +This is primarily done on the Campware site, but also on other +meta-sites, like freshmeat.
    +
    +
    + +