CVS commit of a component.
The official component releases which may be canditates for a pool internal or public release
 have to be clearly distinguished:
Official release:
   Tags should have the format:
                          ComponentName-x-y-z
   where x, y, and z are positive integers which are incremented monotonically according to the rules:
     x : There is a change of the component or external package dependency list affecting the component.
     y : There is a change in the public interfaces (i.e. whatever exists into the pool directory), or any change in the private part of the        component  which affects the semantics of the public interfaces.
     z : There is a change in the private part of the component (i.e. whatever exists in the src directory) not affecting the semantics of the public interfaces.
   The corresponding version of the package is x.y.z
Private release:
Use no tag/private tag. Private tag are left free, taking care to avoid clashes with official tags above defined (reserved: vNVersion, poolNVersion - both upper and lower case). CVS versions with no tag or with unofficial tag are not supposed to be used by anybody else than the developer creating them.
As a general rule, change or remove a tag should be avoided.

Component release.
The committed version on CVS has to be tagged with an official tag, using the convention described above.
Each official release has to be announced by mail to the pool developer list, by specifying (*=mandatory):
 -* release tag
 -* version tags of the other components used (dependencies)
 -* a brief description of the changes
 -  any additional comment/information
Changes to each file should be described in the release.notes file in the doc/ folder.
The source of the component released is expected to use (e.g. to be tested against) the most recent official release of all the components that is depending on.

Pool release tagging.
A pool release is a particular (consistent) set of tagged releases of all components.
   The whole pool tree is tagged with the tag
                                                               pool-x-y-z
   where x, y, and z are positive integers which are incremented monotonically according to the rules:
     x : There is at least one component in the set which comes with a new tag with its x-field updated.
     y : There is at least one component in the set which comes with a new tag with its y-field updated.
     z : There is at least one component in the set which comes with a new tag with its z-field updated.
   During the testing phase the pool tree can be tagged with the format
                                                             pool_x-y-z_cand_i
   where i is a positive integer.

Pool release procedure.
A pool release consists of releasing a set of component tags
   which pass successfully the test procedure. A successfull set is retagged with a new pool global tag.

1) The test/release procedure starts with the submission for testing of one or more component tags. The submission is done by the
   component coordinator, notifying the testing manager of the new proposed tag. The submitted tag has updated code AND documentation.

2) A package with a change in its z-field is tested alone against the last global tag of pool. All its unit tests and the integration and system tests which are affected have to run successfully for the package to be accepted.

3) A package with a change in its y-field is tested as soon as all its dependent packages have been submitted as well. The set is tested against the last global tag of pool. All the components' unit tests and the integration and system tests which are affected have to run successfully for the package to be accepted.

4) A package with a change in its z-field is tested as soon as all the pool packages have submitted a new tag. The whole set of packages are tested together running all unit, integration and system tests.

5) Every time a package or a set of packages succeeds the tests a new glogal tag of pool is produced. If the new candidate version of pool is x.y.z then a series of global tags with the format: pool_x-y-z_cand_i is started. There is a central bookeeping file with the list of component versions for a given global tag which is updated before the actual global tagging. This file is used to assist in the building of the global tag.

7) After a pool_x-y-z_cand_i tag and before the final pool-x-y-z tag all the material related to pool (user/developer/process documentation)
   reflecting the status of the release are updated accordingly.

8) Distribution (i.e. builts in the public release areas) starts after the final tagging, and based on the final tag.

Changes on component interfaces.
By definition, component interfaces are the classes contained in the component pool/ folders (see POOL CVS structure). Since changes can concern other components, they should be previously discussed (in meeting or on pool developer mailing list). Request for changes on the interfaces are expected only when it is really needed (pure 'esthetical' reasons are discouraged).