Software release life cycle

A software release is the distribution, whether public or private, of an initial or new and upgraded version of a computer software product. Each time a software program or system is changed, the programmers and company whose are doing the work, decide when the program or the system is going to be distributed.

This guide try to define the way Pandora FMS and other projects do the things about making public releases of final versions, how move from pure development to “testing” enviroment and when it's ready to become the final version.

The software release life cycle is composed of different stages that describe the stability of a piece of software and the amount of development it requires before final release. Each major version of a product usually goes through a stage when new features are added.


  • Planning
  • Development
  • Beta
  • Final


This phase is used to determine features that will be included in this version, also define the roadmap and timetracking. This phase also could be used to define some interfaces in conceptual way and some other conceptual stuff.

To finish this phase we need to have:

  • Features defined (at least in it's majority).
  • Roadmap defined (at least in it's majority).
  • Barely see a date of finalization for this version.


This is the “big” phase where major development work is done. To finish this phase and starting public testing phase (or beta) we need the following points to be finished :

  • 100% planned functionalities done (see exceptions below).
  • 100% Architecture (DB, API, general architecture) done.

To start Beta phase, we need the consensum of 100% of core developers.


This is an intermediate (and public) phase to show features, but not for production usage. To get the first beta version public, we should be sure that:

  • 100% of interfaces are done.
  • 100% of strings are done.

Obviously, code changes are allowd between different beta versions, only with the purpose of SOLVING PROBLEMS. Any change, except for fix detected problems and exceptions marked below, SHOULD BE avoided.

To start a Beta version, we need :

  • Agreement of 100% of core developers.
  • Project manager agree.
  • Current progress of development is not ready for final version.
  • Need to make a public release for planification / external needs. This could motivate developers to launch a beta version only because “it's needed” externaly.

To get status of final version from a beta version, we need :

  • Agreement of 100% of core developers.
  • Project manager agree.

Exceptions for all phases above

  • Total consensum for core developers on changes.
  • External imposition (dates, customer, god) and without consensum of all core developers, could be implemented using a temporaly development branch.

Final version

This is the stable and ready for production usage. This also could contain bugs that will be released as patches/hotfixes or even as a fixed subversion, for example, from a 1.3 version, let's go to 1.3.1. Final versions will be maintained in a independent and parallel branch of code in code repositories.