Copyright © 2007 Cédric Delfosse - Mandriva
| Revision History | ||
|---|---|---|
| Revision $Revision: 84 $ | $Date: 2007-12-03 15:11:53 +0100 (Mon, 03 Dec 2007) $ | $Author: cedric $ |
Abstract
This document explains how to release a new MMC version.
Table of Contents
What we release are:
A tarball called mmc-agent-VERSION.tar.gz. It contains the mmc-agent and all its Python plugins.
A tarball called mmc-web-base-VERSION.tar.gz. It contains the base MMC web administration framework and the base LDAP related management functions.
A tarball called mmc-web-samba-VERSION.tar.gz. It contains the SAMBA web administration module.
A tarball called mmc-web-ox-VERSION.tar.gz. It contains the Open-Xchange web administration module.
A tarball called mmc-web-proxy-VERSION.tar.gz. It contains the proxy blacklist (squid/squidguard) administration module.
A tarball called mmc-doc-VERSION.tar.gz. It contains all the MMC related documentation.
Beware that mmc-agent requirements must be met before mmc-web-* one.
Please check the requirements in this order.
All the python unit tests runs succesfully.
For the agent and each plugin, the VERSION attribute must be
updated to the version number we release, in those files:
mmc/agent.py mmc/plugin/base/__init__.py
mmc/plugin/samba/__init__.py mmc/plugin/proxy/__init__.py
mmc/plugin/ox/__init__.py.
For each plugin, the APIVERSION attribute may be updated. The APIVERSION string is similar to libtool library versions: current:revision:age.
current : The most recent interface number that this library implements.
revision : The most recent interface number that this library implements.
age : The difference between the newest and oldest interfaces that this library implements. In other words, the library implements all the interface numbers in the range from number current - age to current.
Here are a set of rules to update the APIVERSION string:
If a Python plugin source code has changed at all since the last release, then increment revision (c:r:a becomes c:r+1:a)
If any interfaces have been added, removed, or changed since the last release, increment current, and set revision to 0
If any interfaces have been added since the last release, then increment age
If any interfaces have been removed since the last public release, then set age to 0.
Please check the requirements in this order.
The version attribute contained in each infoPackage.inc.php file from each mmc-web-* component must be updated to the version we release, thanks to the setVersion method.
Each mmc-web-* must be able to interact with their corresponding plugin we are going to release. For example, mmc-web-base must be compatible with the base plugin of the mmc-agent. The APIVersion variable contained in each infoPackage.inc.php file from each mmc-web-* must be equal to the APIVERSION attribute of the corresponding mmc-agent Python plugin. This is done thanks to the setAPIVersion method.
The web selenium tests are successful with the mmc-agent revision we are going to release and that met the release requirement.
The manual tests of the web interface are successful.
All the installation/configuration manuals must be updated and checked.
The Python API documentation must be regenerated. This is done automatically every day.
The PHP API documentation must be regenerated. This is done automatically every day.
The Changelog file must be updated. If an entry in the changelog is a bugfix of a bug reported in the bug tracking system, the ticket number must be written.
The mmc-agent SVN repository is tagged according to the version number of the release. The tag format is MMC_x_y_z. For example, if the version we release is 1.2.3, the tag is MMC_1_2_3.
We export the source code from the SVN repository with the tag
we just set, to a directory called mmc-agent-x.y.z.
A tarball called mmc-agent-x.y.z.tar.gz is built from this directory.
The Changelog file of each component must be updated. If an entry in the changelog is a bugfix of a bug reported in the bug tracking system, the ticket number must be written.
All the mmc-web-* SVN repositories are tagged according to the version number of the release. The tag format is MMC_x_y_z. For example, if the version we release is 1.2.3, the tag is MMC_1_2_3.
We export the source code from the SVN repositories with the tag
we just set, to directories called mmc-web-*-x.y.z (for example mmc-web-base-1.2.3).
Tarballs called mmc-web-*-x.y.z.tar.gz are built from this directory.
The Changelog file must be updated. If an entry in the changelog is a bugfix of a bug reported in the bug tracking system, the ticket number must be written.
The mmc-doc SVN repository is tagged according to the version number of the release. The tag format is MMC_x_y_z. For example, if the version we release is 1.2.3, the tag is MMC_1_2_3.
We export the source code from the SVN repository with the tag
we just set, to a directory called mmc-doc-x.y.z.
A tarball called mmc-doc-x.y.z.tar.gz is built from this directory.
The tarballs are put in the public download place.
The debian packages repository is updated, for Sarge and Etch (Cédric Delfosse).
The RPMs packages repository for Mandriva CS4 and Mandriva 2008 are updateed (Oden Eriksson).
The VMware image is updated thanks to the RPM packages.
A mail is sent to the mds-announce mailing list.
The freshmeat entry is updated.