A detailed description of the steps follows:

• Submit checkout package - Release czar posts a request to Release Server to commence a test release, consisting of a package name and proposed release tag. The requirements file for the checkout package will, as usual, be expected to explicitly specify tags for all dependant packages. Access will initially be via web and command line interfaces (Alex and Karl have both developed prototypes).
• Create branches - For each dependant package a branch will automatically be created and all development towards the release will be done on that branch. An attempt will be made to use suggestive tags, e.g. v10r2-branch1.
• Build - An attempt will be made to build the package (eventually on all platforms when the underlying common build package is available - Alex and Toby are currently discussing a strategy for producing this). For now the automated procedure will occur on linux and the release czar or a designee will be responsible for the Windows build. If the build succeeds the Release Server proceeds to the test stage, if not it proceeds to the error reporting stage.
• Test  - An attempt will be made to run unit and system tests for the checkout package (again, eventually on all platforms). If the tests run and produce acceptable results the Release Server proceeds to the tag stage, if not it proceeds to the error reporting stage.
• Tag - Once the build and test stages have succeeded an attempt will be made to merge the branched versions of all the dependant packages with the main trunk. If development has continued on the main trunk in a way that creates conflicts with the branched version the Release Server proceeds to the error reporting stage so that the package owner can resolve the conflict. If no such conflict occurs a release is declared and the checkout package and its dependant packages are moved to the vat.
• Report Errors - If there are any build or test errors for a given package, email describing the errors is sent to the package owner, the release czar (and any other designees). It is then the responsibility of the package owner to attempt a fix. A commit to the release branch for the package will trigger the Release Server to begin again at the Build stage described above. Note that with this model errors are addressed serially. On one hand this creates a bottleneck, on the other it avoids "race" conditions, i.e. inconsistent updates applied simultaneously.
• Modify Packages - Provided with an error report, package owners are expected to attend to the problem as described above.      

K.Young Last Modified: 05/07/2002 10:54