-- DoinaCristinaAiftimiei - 03-Sep-2010

Task SA1.3: - Release Management

Task Description

This task deals with release management and coordination and the maintenance of the package repositories, defining policies and release cycles. This task also covers the smooth transition from many middleware distributions to one, so that the production infrastructures stay functional without noticeable discontinuity.


  • DSA1.2 - Software Release Plan - End of July 2010 - DeliverableDSA12
  • MSA1.2.1 - EMI Reference Releases - End of Oct 2010
  • MSA1.2.2 - EMI Reference Releases - End of Apr 2011
  • MSA1.2.2 - EMI Reference Releases - End of Apr 2012
  • MSA1.2.3 - EMI Reference Releases - End of Apr 2013

EMI Releases

  • The EMI distribution will be organized in periodic major releases, tentatively delivered once a year [MSA1.2.2, MSA1.2.2 and MSA1.2.4], providing a good balance between the conflicting requirements of stability and innovation.
  • An EMI major release is characterized by well-defined interfaces, behavior and dependencies for all included components, available on a predefined set of platforms. What is included in a new EMI major release is defined by the PTB and the implementation of the plan is coordinated by JRA1 [MJRA1.19.1, MJRA1.19.2 and MJRA1.19.3].

Actors & Roles

  • Developers - are responsible for the maintenance of a particular part of the code, which includes fixing bugs and adding new features to software components. They can belong to one or more Product Teams, depending on the components they are developing.
  • Product Team (PT) – small teams of software developers, fully responsible for the successful release of a particular software product (or group of tightly related products) compliant with agreed sets of technical specification and acceptance criteria. The individual Product Teams are requested to execute the necessary processes and procedures and respect established requirements and priorities as globally defined and endorsed by the EMI project executive and technical leadership.
  • Product Team Leader (PTL) - responsible for managing a specific PT, for the design, development, support and maintenance of specific products
  • Software Quality Control Leader (SQCL) - responsible for the Software Quality Control layer, which ensures both SQA and SQAP are being followed by the development teams. All the releases of EMI components need to satisfy well-defined certification and validation criteria before being included in a stable EMI distribution, sufficient to guarantee to a high degree of confidence that all EMI products meet or exceed the requirements set by EGI and that no regression are introduced.
  • Technical Area Coordinator: the members of the Project Technical Board responsible for the overall coordination of each of the four technical areas: compute, data, infrastructure and security areas. The TACs are responsible to define together with the relevant Product Team Leaders the technical strategy of their area. They are also responsible to define together with the TD and the other TACs the overall project technical plans. The TAC are proposed by the PD and the TD and approved by the CB.
  • Release Manager: - responsible for overall coordination. Main duties include: assure the good functioning of the release process, manage release delivery and scheduling, chair the EMT and ensure that its agenda reflects all relevant issues of the day.

  • Decision-Making bodies:
    • Engineering Management Team (EMT)
    • Project Technical Board (PTB)
    • Project Executive Board (PEB)

Release Categories

An EMI distribution includes all the components that are developed within the project and that have reached production quality. Within an EMI major release, only one version of a given component is maintained. Four types of releases have been identified for a given component:
  • Major Release: a major release for a component
    • is characterized by a well-defined interface and behavior, potentially incompatible with the interface or behavior of a previous release.
    • can be introduced only in a new major release of EMI.
    • the contents of a new major release are endorsed by the PTB and included in the project technical plan.
    • the implementation is coordinated by JRA1.
  • Minor Release: a minor release of a component
    • includes significant interface or behavior changes that are backwards-compatible with those of the corresponding major release.
    • can be introduced in an existing major release of EMI.
    • the contents of a new minor release are endorsed by the PTB and included in the project technical plan.
    • the implementation is coordinated by JRA1.
    • if the release is going to be introduced in an existing major release of EMI, the implementation is also supervised by SA1 in order to guarantee that the production quality and the backwards-compatibility are preserved.
  • Revision Release: a revision release of a component
    • includes changes fixing specific defects found in production and represents the typical kind of release of a component during the lifetime of an EMI major release.
  • Emergency Release: an emergency release of a component
    • includes changes fixing only Immediate-priority defects found in production, typically security-related.


Guidelines, maintained by SA2-WP, to be followed during the software development process:


Major Release Schedule Methodology

Task/Milestone Start Day Length
Planning & Development Day after the end of the Planning phase for the previous GA Release More than 5 months
Feature Submission Deadline 5-8 months before the Feature Freeze n/a
Feature Freeze 2 month before the RC (Dic 20xx) Until GA
Testing & Certification 1 day after the Feature Freeze 2 months
Feature Complete 1 month after the Testing & Certification begin 1 month
Final Change Deadline
(code freeze)
End of Testing & Certification Until GA
Release Candidate End of Testing & Certification
Start Acceptance Testing
2 months before GA-release day (Feb 20xx)
3 days after the Final Change Deadline
Until GA
Compose Final RC Same as Release Candidate 1 week
Technical-Previews 1 month before the GA Should last 2 weeks
Test Final RC 2 weeks before GA 6 days
GA Release April 30, 20xx n/a
Maintenance GA release day ~2 years
End of Life 2 years after the GA of current release n/a


  • Feature Submission Deadline:
    • final date that new features can be submitted to the release;
    • new features must be submitted to next release.
  • Feature Freeze:
    • feature development is complete or in a significantly complete state so that the feature can be adequately tested;
    • after the Feature Freeze: new enhancements should not be added; changes to components that require other (dependent) software components to make changes as well, should be avoided;
    • for introducing exceptions an exception process and evaluation will be defined.
  • Feature Complete:
    • software components contain all intended functionality of the final version;
    • still have to undergo testing and bug fixing, performance or stability enhancement before they can become Release Candidates.
  • Final Change Deadline:
    • code freeze date meaning that no changes whatsoever are permitted to components source code. Critical components, components on which others depend, will have a different code freeze calendar;
    • no more updates are made to the emi-dev repository; packages are moved to the emi-test repository.
  • GA Release – General Availability Release:
    • software components are delivered to Customers

EMI package signing procedure

EMI Beta & Acceptance Testing activity

EMI Major Releases

EMI-0 (Zugspitze)

An ‘exercise’ release designed to understand how to apply the agreed procedures, find any problem about tools and processes and in general fine tune the EMI software engineering process before the EMI 1 release. The outcome of EMI 0 is not expected to be released to external users. The goal of EMI 0 is to prepare a consistent, coherent repository of non-conflicting packages by the end of October 2010 without any specific commitment on functionality.

EMI-0 Activity

EMI-1 (Kebnekaise)

EMI-2 (Matterhorn)

EMI-3 (Monte Bianco)

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatods EMI2.gantt.2.ods r1 manage 25.6 K 2011-08-09 - 17:59 DoinaCristinaAiftimiei EMi 2 roadmap - gantt
Microsoft Excel Spreadsheetxls EMI2.gantt.2.xls r1 manage 13.5 K 2011-08-09 - 18:01 DoinaCristinaAiftimiei EMI 2 roadmap - gantt
Unknown file formatodp Road_Matterhorn_AHM2011_v06.odp r1 manage 460.6 K 2011-08-02 - 11:57 DoinaCristinaAiftimiei Road to Matterhorn
PDFpdf Road_Matterhorn_AHM2011_v06.pdf r1 manage 403.0 K 2011-08-02 - 11:58 DoinaCristinaAiftimiei Road to Matterhorn
Texttxt list_externals_names_64_v3.txt r1 manage 1.3 K 2010-09-28 - 10:38 DoinaCristinaAiftimiei list of external dependencies names available on SL5/EPEL (x86_64) repos
Texttxt list_externals_names_64_v4.txt r1 manage 1.4 K 2010-09-30 - 10:12 DoinaCristinaAiftimiei list of external dependencies names available on SL5/EPEL (x86_64) repos (after Vincenzo's comments)
Texttxt list_externals_names_debian_lenny.txt r1 manage 1.3 K 2010-09-27 - 12:21 DoinaCristinaAiftimiei list of external dependencies names available on Debian5-stable (Lenny) repos
Texttxt list_externals_names_debian_lenny_v2.txt r1 manage 1.4 K 2010-09-30 - 10:41 DoinaCristinaAiftimiei list of external dependencies names available on Debian5-stable (Lenny) repos (after Vincenzo's comments)
Texttxt list_externals_names_debian_squeeze_sid.txt r1 manage 0.6 K 2010-09-27 - 12:22 DoinaCristinaAiftimiei list of external dependencies names available on Debian5-testing (Squeeze) repos
Edit | Attach | Watch | Print version | History: r76 < r75 < r74 < r73 < r72 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r76 - 2012-11-12 - DoinaCristinaAiftimiei
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EMI All webs login

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