-- AndreiTsaregorodtsev - 14-Dec-2009

DIRAC Release Procedure

This document aims at defining the procedures for a new release of DIRAC to be put together, certified and then rolled out. The purpose of these procedures is to ensure a reliable while reasonably fast deployment of new software. The DIRAC release procedure consists of several well defined steps.

Decision about the new release

It starts with the decision for making a new release. A new DIRAC version may be required for several reasons. Each of these releases correspond to a change in one of the fields of the version name that is of the form v.r.p.

  • Bug fix or technical fix: change p field
  • New features added: change r field
  • Changes to interfaces or packaging (incompatible with previous releases): change v field
Once the decision is taken by the release manage based on discussions in the project meeting or e-mail exchange, it is announced to the development team.

Tagging subsystems.

The DIRAC software is organized in several packages (DIRAC, LHCbDIRAC, VO specific packages ). The code for each package is located in the top level directories in the code SVN repository with the same names as the package name. Each package contains several subsystems which code is located in the corresponding subdirectories of the package directories.

All the persons responsible for subsystems are tagging their respective subsystems using SVN commands directly or the corresponding Eclipse tools. Each subdirectory under DIRAC or LHCbDIRAC must be tagged before making a release.

The svn command to tag is:

  • svn copy $SVNROOT/DIRAC/trunk/DIRAC/Subsystem $SVNROOT/DIRAC/tags/DIRAC/Subsystem/newtag
    -- to do server side tagging
  • svn copy <LocalSubsystemPath> $SVNROOT/DIRAC/tags/DIRAC/Subsystem/newtag
    -- to base it on the local checked out copy of the system. Here SVNROOT is currently svn+ssh://svn.cern.ch/reps/dirac

The latter way of tagging can be useful if we want to tag the directory where some files are committed but not yet ready to go into the release and should not be tagged. The subsystem tags are communicated to the release manager. The message can be that no new tag is needed for the subsystem.

Making tags of a package (DIRAC, LHCbDIRAC)

This is done by editing the corresponding versions.cfg files by the release manager. The subpackage release notes are given as comments to corresponding subsystem entries. An example of the versions file is below.

Versions
{
  # NEW: new functionality in this DIRAC release
  # CHANGE: functionality modification in this DIRAC release
  # BUGFIX: important bug fix in this DIRAC release
  v5r0p0-pre1
  {
   # NEW: new functionality in this system release
   # CHANGE: functionality modification in this system release
   # BUGFIX: important bug fix in this system release
    AccountingSystem = ac_2009120301
    ConfigurationSystem = cs_2009120301
    Core = co_2009120301
    DataManagementSystem = dm_2009120301
    FrameworkSystem = fm_2009120301
    Interfaces = if_2009120301
    RequestManagementSystem = rq_2009120301
    Resources = re_2009120301
    ResourceStatusSystem = rs_2009120301
    StagerSystem = ss_2009120301
    StorageManagementSystem = sm_2009120301
    TransformationSystem = tr_2009120301
    WorkloadManagementSystem = wm_2009120301
  }
}

Once the versions.cfg is updated the package tag is generated using dirac-create-svn-tag command:

 dirac-create-svn-tag -v <project_tag> -p <project_name> 

Release notes

The release notes are also put into the versions.cfg file in a form of comments to the appropriate system entry or general notes for the whole package release version. Each note is preceded by one of the three quilifiers - NEW, CHANGE or BUGFIX - followed by a colon as shown in the example. These release notes are extracted, combined in a well formated html and pdf documents.

Making a global tag

This is done by editing the releases.cfg file by the release manager.

Releases
{
  v5r0p0-pre1
  {
    DIRAC = v5r0p0-pre1
    LHCbDIRAC = test
    Web = trunk
    Externals = trunk
  }
  #This tag will always be the trunk of all packages
  HEAD
  {
    DIRAC = trunk
    LHCbDIRAC = trunk
    Web = trunk
    Externals = trunk
  }
}

Building distributions

Python only distribution

  • dirac-distribution -r <global_tag> -t client,server -El

Externals distribution

  • dirac-distribution -r <global_tag> -t client,server -PL 

Note that to build a binary distribution you will have to have an already functional client installation for this platform. This is achieved by running dirac-install with -b flag

Prereleases

Before the release is going into production, it is tested in the Certification DIRAC Setup. For this testing it can go through a series of prereleases. The prerelease version has a form vXrYpZ-preA, where X,Y,Z,A are numbers. After the Certification tests are finished, the final version is of the form vXrYpZ. Once the final release is out, the prerelease versions are removed from the distribution area and the prerelease tags are removed from SVN and from version.cfg/release.cfg files

Edit | Attach | Watch | Print version | History: r12 < r11 < r10 < r9 < r8 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r12 - 2011-03-01 - AndreiTsaregorodtsev
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LHCb All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback