Once a major/minor release has reached the Stable phase in the [[Development Cycle]] the processes and procedures for development change. The most immediate thing to notice is that the development is no longer driven by the [[Development Team]] when the Stable phase is reached. As soon as the major/minor release is declared stable all future development on that release is driven by the [[Bug Squad]]. It is important to understand the way we think about a [[Maintenance Release]] because one of the things that our community depends upon is stability. Stability is born of a rigorous testing process and accountability. This document will outline the procedures and processes for maintaining a Joomla! major/minor release.

Once a major/minor release has reached the Stable phase in the [[Development Cycle]] the processes and procedures for development change. The most immediate thing to notice is that the development is no longer driven by the [[Development Team]] when the Stable phase is reached. As soon as the major/minor release is declared stable all future development on that release is driven by the [[Bug Squad]]. It is important to understand the way we think about a [[Maintenance Release]] because one of the things that our community depends upon is stability. Stability is born of a rigorous testing process and accountability. This document will outline the procedures and processes for maintaining a Joomla! major/minor release.

−

Once a release has been declared stable ([[Maintenance Release]]), all bugs and artifacts are to be tracked in our official [[Tracker]] on the Joomla! GForge site: [http://www.joomlacode.org]. Having a single place for confirmed issue tracking provides us all with a simple system of accountability.

+

Once a release has been declared stable ([[Maintenance Release]]), all bugs and issues are to be tracked in our official [http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=32 Joomla! Tracker] on the [http://www.joomlacode.org Joomla! GForge site]. Having a single place for confirmed issue tracking provides us all with a simple system of accountability.

The maintenance procedures have the following stages :

The maintenance procedures have the following stages :

−

* [[Reporting issues]]; We keep track on the open issues in our [[Tracker]] but issues can be reported in two ways: from the forum or directly into the tracker. A description of the process of [[Reporting issues]] is available (click the link).

+

* [[Bug Tracking Process#Reporting Issues|Reporting Issues]]; We keep track on the open issues in the tracker, but issues can be reported in two ways: from the forum or directly into the tracker.

−

* [[Resolving issues]]; Once an issue is confirmed, there are several ways it can get solved. First members from the [[Development team]] can work on solving the issue, but also community members can send in patches. The general way of working is: create patch, test patch, commit patch. A description of the [[Resolving issues]] process is available (click the link).

+

* [[Bug Tracking Process#Resolving Issues|Resolving Issues]]; Once an issue is confirmed, there are several ways it can get solved. First members from the [[Development Team]] can work on solving the issue, but also community members can send in patches. The general way of working is: create patch, test patch, commit patch.

−

The maintenance procedures implement the Quality processes for Joomla!. This process differs only during the development stage of a major release or a minor release in the [[resolving issues]] process. In maintenance releases we work with patches, and within the [[Development Cycle]] of a major release or a minor release developers will fix issues directly in the trunk until the codebase reaches a stage of [[Development Cycle|Release Candidate]].

+

The maintenance procedures implement the Quality processes for Joomla!. This process differs only during the development stage of a major release or a minor release in the [[Bug Tracking Process#Resolving Issues|resolving issues]] process. In maintenance releases we work with patches, and within the [[Development Cycle]] of a major release or a minor release developers will fix issues directly in the trunk until the codebase reaches a stage of [[Development Cycle|Release Candidate]].

Latest revision as of 15:31, 7 June 2009

Once a major/minor release has reached the Stable phase in the Development Cycle the processes and procedures for development change. The most immediate thing to notice is that the development is no longer driven by the Development Team when the Stable phase is reached. As soon as the major/minor release is declared stable all future development on that release is driven by the Bug Squad. It is important to understand the way we think about a Maintenance Release because one of the things that our community depends upon is stability. Stability is born of a rigorous testing process and accountability. This document will outline the procedures and processes for maintaining a Joomla! major/minor release.

Once a release has been declared stable (Maintenance Release), all bugs and issues are to be tracked in our official Joomla! Tracker on the Joomla! GForge site. Having a single place for confirmed issue tracking provides us all with a simple system of accountability.

The maintenance procedures have the following stages :

Reporting Issues; We keep track on the open issues in the tracker, but issues can be reported in two ways: from the forum or directly into the tracker.

Resolving Issues; Once an issue is confirmed, there are several ways it can get solved. First members from the Development Team can work on solving the issue, but also community members can send in patches. The general way of working is: create patch, test patch, commit patch.

The maintenance procedures implement the Quality processes for Joomla!. This process differs only during the development stage of a major release or a minor release in the resolving issues process. In maintenance releases we work with patches, and within the Development Cycle of a major release or a minor release developers will fix issues directly in the trunk until the codebase reaches a stage of Release Candidate.