Agasti Release Strategy


This document outlines the Sahana Agasti release strategy.

The Sahana Software Foundation Sahana Agasti project is a highly modular php-based web application. This application is comprised of a number of independent packages with interrelated dependencies and support levels. Each package, including the core framework, will possess its own branches, versioning scheme, support teams, and governance structure.

Collections of these packages that have been tested against one another and prepared for release are referred to as series. Series are defined by their Release Planning Documents. These documents outline the bare-minimum functionality that must be achieved before a new release will be approved and published.

At any one point in time Sahana Agasti will have three active series, one in each phase of the release process. Each series possesses a unique support strategy, team composition, and quality assurance process. Series names are unique to the release major version but may have a number of related milestones for minor versions.


For the purpose of this document it is important to note that the terms package and module are not used wholly interchangeably. A package is an any single bundled piece of software. This could be a module, an external data-processing engine, or the web-framework upon which Sahana Agasti is built. Modules are a special type of package that provide pluggable functionality to the Sahana Agasti application. These are synonymous with what other projects may call plugins or extensions.


The Sahana Agasti application is, at its essence, a distribution of pluggable unique emergency response applications bound by a framework. These applications are made interoperable by the API, code, documentation, quality standards and development guidelines established by the Sahana Agasti project and its parent organization, the Sahana Software Foundation. Modules are expected to have their own governance structure and development strategy including, but not limited to, timeline management, versioning schemes, and test strategies and are effectively positioned as upstream software providers. In order to be considered for inclusion in a subsequent release series modules must possess a license compatible with the license of the Sahana Agasti parent project and must comply with the Sahana Agasti Module Standards.

Priority Levels

Packages and release criterion are organized by a series of priority levels. These priority levels allow the release team and maintainers to separate high-priority targets from less-important ones.

The following priority levels are used by the Sahana Agasti project.

  • required: Affects the most basic functioning of the system such as “works over HTTP.” These priority levels will almost exclusively relate to core repository packages.
  • important: Required for basic inter-process operations. An example of a function with this priority level is “Successful import of a module.” These priority levels will almost exclusively relate to core repository packages.
  • standard: Affects the basic functionality of the application such as secure password authentication or sending an email.
  • optional: Affects most functionality within the application. Does not cause a priority conflict with other priority levels.
  • extra: Affects functionality that could cause a conflict with functionality in other priority levels.

Software Versioning

Major releases of Sahana Agasti are referred to as Series. Each series is required to have a name and be numbered sequentially. Within each series are a number of minor releases referred to as Milestones. Milestones must have a unique name related to their function and should be numbered, where appropriate, for differentiation.

Series Naming Conventions

Series names will be voted upon by the release team and first published as part of the Release Planning Document. The series names should be unique within the project and avoid lewdness and political or religious discourse that would otherwise alienate potential participants or consumers.

Example Series

The Flower project has three series. Each of the three series has a number of milestones.

  • Series: Poinsettia
    • Milestone: Poinsettia Alpha 1
    • Milestone: Poinsettia Beta 1
    • Milestone: Poinsettia Beta 2
    • Milestone: Poinsettia Release Candidate 1
    • Milestone: Poinsettia Release (1.0)
    • Milestone: Poinsettia Release Updates (1.1)
  • Series: Tulip
    • Milestone: Tulip Alpha 1
    • Milestone: Tulip Beta 1
    • Milestone: Tulip Beta 2
    • Milestone: Tulip Release Candidate 1
    • Milestone: Tulip Release (2.0)
  • Series: Daffodil
    • Milestone: Daffodil Alpha 1
    • Milestone: Daffodil Alpha 2


Packages developed for the Sahana Agasti project will be divided into three supported repositories. Package inclusion in a given repository will dictate the package's support level and installation-guidelines.

Supported repositories include:

  • Core: Packages and internal software developed by the core Sahana Agasti dev team. These packages are strictly limited to API, interoperability, framework customization, and module-handling procedures. Core packages receive the highest level of support and review and are the first packages to be frozen during the release process. Packages in the Core repository receive regular audits by the security team.
  • Main: Modules that are stable with a well-tested history in the field that directly coincide with the mission of the Sahana Agasti software project and provide valuable functionality to end-users. Modules in the Main repository undergo stringent review for quality, security, and load standards and are packaged as part of major releases. Main repository modules receive regular security audits by the security team.
  • Contrib: Modules that have passed quality, security, and load standards but have not received sufficient testing in the field, do not wholly align with the mission of the Sahana Agasti project, or do not provide valuable functionality. Contrib modules are not included by-default in major releases but will be tested against major releases by the release team and hosted by the Sahana Agasti project. Modules in this repository will receive infrequent audits by the security team.

All packages in these repositories will be formally supported on the Sahana Agasti project bug tracker.


As part of the ongoing process of creating quality software the Sahana Agasti project is continually reviewing new ideas and features for inclusion in a future release. These ideas are collected and hosted on the Sahana Agasti project bugtracker. A number of guidelines have been established on the Agasti Specifications page which provides a suggested specification template. Review Team members are more likely to include specifications that are well-written in future releases.


A number of teams are involved in bringing a release to fruition. The totality of these teams is collectively referred to as a Release Team. As membership in the various teams changes it is expected that each Release Team will have a subsequently altered composition. Teams that comprise a release team include:

  • Sahana Agasti PMC: Provides high-level guidance and project management for the project, holds the Release Planning meeting and sets the initial Release Schedule.
  • Review Team: Reviews specifications and proposals, maintains the RPD, maintains the release schedule, pulls new packages or features into the release plan.
  • Core Developers: Maintain the core functionality and featureset, pull in new core upstream packages, and dictate important API, schema, and ui decisions.
  • Package Managers: Pull new versions of non-core packages from upstream providers, perform conflict resolution testing and architecture and build testing.
  • Doc Team: Updates and creates documentation for the new release and maintains the release wiki.
  • Security Team: Performs new and ongoing security analysis and audits and provides immediate and upstream patches.
  • QA Team: Provide targeted qa testing to ensure inter-module cohesion and quality-assurance standards have been maintained.
  • Localization Team: Creates and updates translations and localizations.
  • Usability Team: Creates and maintains Agasti design templates and artwork.
  • Bug Wranglers: Maintain the bug tracker by effectively triaging bugs and notifying the appropriate authorities for fixes.
  • Build Team: Packages releases together in package manager packages, livecd's, etc.

Other notable teams who are not part of the release team include:

  • Customization Team: Focuses on creating and maintaining customized distributions and working with upstream maintainers to identify notable functionality improvements and ease the process of patching upstream.

All teams are more adequately explained in the Sahana Agasti Developer Workflow page.


The Sahana Agasti project adopts a hybridized approach to releases that combines limited timeboxing for administrative functions with a when it's done approach to actual development. Releases occur when all of the criterion in a Release Planning Document have been met and when there are no release-critical bugs.


Release-critical bugs (also know as RC bugs) are bugs that prevent a series from fulfilling its RPD series requirements. See the Active Series section below for more details on series requirements.

Active Series

At any one given point-in-time the Sahana Agasti project has three active series. These series occupy the traditional roles of a stable release, an unstable release, and an experimental release. As a new release occurs unstable will become stable, experimental will become unstable, and a new experimental series will be built from the most recent builds of upstream packages.

Series Migration

Series Old Role New Role
release 1.0 stable deprecated
release 2.0 unstable stable
release 3.0 experimental unstable
release 4.0 none experimental

Series Requirements

  • Stable
    • Meets all criterion in the Release Planning Document
    • Packaged for and tested on all architectures and build-targets
    • Tested to all specified load and performance targets
    • Conforms with all documentation, security, and software quality standards
    • Fully translated in all required languages
    • Updates seamlessly from previous versions
    • Only receives security updates
  • Unstable
    • Meets all required, important, and standard criterion in the Release Planning Document
    • Packaged for and tested on important and standard architectures and build targets
    • Tested to important and standard load and performance targets
    • Conforms with all documentation, security, and software quality standards
    • Fully translated in important and standard languages
    • Does not guarantee seamless updates
    • Receives security updates and limited package updates
  • Experimental
    • Utilizes the newest compatible upstream packages and modules
    • May not meet all criterion in the Release Planning Document
    • Undergoing testing on architectures and build targets
    • Undergoing testing on load and performance targets
    • May not conform to documentation standards
    • Conforms to security and software quality standards
    • May not be fully translated
    • May not possess update support
    • Receives no security audits
    • Has regular package updates

Release Manager

At the beginning of each release cycle the Sahana Agasti PMC will nominate and appoint a Release Manager from within the Sahana Agasti project membership. Ideal Release Managers will have demonstrated excellent project management skills, commendable writing ability, a strong devotion to the project, and possess a working knowledge of the release procedure and Sahana Agasti project membership. While not a requirement, strong preference should be given to candidates who have previously served on a Series Review Team.

Release Managers will interact with and coordinate the efforts of all project teams throughout a series release and function as the Chair of the series Review Team. Release Managers are not required to be Sahana Agasti PMC members prior to selection but will become so upon assuming office for the duration of their tenure as a Release Manager.

Each active series will only have one concurrent Release Manager. It is possible for one individual to be the Release Manager for more than one active series; however, the position is not a permanent one within the Sahana Agasti project leadership and Release Managers must be re-selected by the PMC with the creation of each new series.

In the event that a Release Manager is unable or unwilling to perform his or her duties, and/or is deemed derelict in the completion of his or her duties, the Sahana Agasti PMC will hold a vote to dismiss the Release Manager in question and begin immediate proceedings to select a new Release Manager from the existing Review Team. In the event that a suitable candidate cannot be found, the Sahana Agasti PMC Chairperson will assume these duties until such a point in time as a new Release Manager can be established.

Release Planning Document

Following the election of the Release Manager, the Sahana Agasti project membership (which can be different from the upstream module developers), will agree upon a number of prioritized functional targets built from its pool of specifications. The Release Manager is responsible for setting the schedule and timeline for this process and for compiling the specifications into a Release Planning Document (RPD) that will establish a new series. Once the Release Planning Document has been created it comes under the governance of the Review Team who have limited powers of change over the document until the FeatureFreeze. This document will follow a consistent outline and contain the following elements.

Release Name

Discussed above, the release name must be unique and will be selected by project members.

Release Statement

The release statement is a narrative statement, no more than a few paragraphs, that outlines the major goals for the release.

Release Team

This section details the members of this specific release team.

Notable Package Overview

This overview should quickly identify the major build, platform, and architecture targets of the release.

These targets include but are not limited to:

  • Upstream server versions (eg, Mysql, Apache, IIS)
  • Out-of-box OS support (eg, Linux distro, Windows version)
  • Architecture support
  • Language support

Notable Functionality

This section should provide a simple bullet list of notable new functionality provided by the packages of this release.

Core Package Detail

In this section, core packages will be discussed at some length. Core packages that are provided upstream will have their target versions identified with a brief outline of any notable changes. Those that are developed under the Sahana Agasti project will be discussed in Release Planning Document TEMPLATEmore depth.

Package Listing

The final section of the RPD will be a listing of packages that will be included in the new release. This list should be in a tabular format with both the new and current package versions identified. Special note should be given to packages that have been removed or deprecated.

A sample RPD document can be found on the Release Planning Document Template page.

Release Schedule

The Sahana Agasti release schedule is initially set by the Sahana Agasti PMC but is afterwards maintained by the Review Team. The release schedule starts with the establishment of a new experimental. The release schedule can be found below:


  • Release Planning (4-6w): Specifications are reviewed, targets are created, a name is selected, and an RPD is created.
  • Infrastructure Setup (1w): New branches on launchpad are cloned from the current experimental, the toolchain is organized, and any relevant bug and wiki documents are created.
    • RPD Publicaton: The new RPD is published and teams are allowed access to begin developing on the new series.
  • Upstream Merge (< 3mo): Upstream packages are merged into the new branch.
    • UpstreamFreeze: At the end of the upstream merge all packages have their versions frozen (eg, no new upstream versions will be included).
  • Development (∞): Features are developed according to the RPD and changes made to packages are pushed upstream.
    • CoreFreeze: All glue-API's in the core have been dictated or adapted as-necessary to achieve the goals of the RPD and changes to the core packages are disallowed.
    • FeatureFreeze: Only bug fixes are allowed beyond this point — no new features, packages, or APIs.
    • UiFreeze: User interface changes are disallowed beyond this point.
  • Documentation & Testing (∞): Security, quality, and performance testing begin and the documentation team starts compiling all required documentation.
    • DocFreeze: No more changes are allowed on the developer and end-user documentation (this is to allow the customization team to work on translation efforts)
  • RC Bughunt (∞): Release critical bugs in experimental are fixed.
  • Packaging (∞): Experimental branch is packaged for the important and standard architectures.
    • Assuming the current unstable has no RC bugs, unstable becomes stable, experimental becomes unstable, and a new experimental is built.


  • Translation (∞): The application is translated into its stable target languages.
  • Performance Testing (∞): The application undergoes performance testing and results figures are published.
  • Migration Development (∞): Migration and update scripts are finalized.
  • Beta Packaging (∞): The application is packaged for all release architectures.
    • BetaFreeze: The application is frozen for beta testing
  • Beta Testing & RC Bughunt (∞): Any outstanding release critical bugs in unstable are fixed.
  • Release Candidate Packaging (∞): The release candidate is packaged for all release architectures.
  • Release Candidate (1mo): Application is currently frozen while end-users utilize it.
  • Release Packaging (∞): The release candidate is packaged for all release architectures. Packaging includes the creation of a formal changelog to be included with the release as well as posted with the release announcement.
    • Assuming the current experimental has no RC bugs, unstable becomes stable, experimental becomes unstable, and a new experimental is built.


  • Updates: Only security updates are allowed during this period
    • Updates Packaging: In rare circumstances where a stable version has undergone important security updates or has been stable for a long period, it may be reasonable to re-package the application and re-release it with a new minor number.
    • At the next rotation, when the current unstable becomes stable, this branch becomes an obsolete series.

Under special circumstances, exceptions to this process can be made at the discretion of the Review Team. Rules for these exceptions may be found in the Release Freeze Exceptions page.

QR Code
QR Code agasti:release_strategy (generated for current page)