The Software Release Tools--or SRT as often abbreviated in this manual--is a suite of tools and other facilities for the developers of relatively large and complex software systems. It is assumed that the software is developed concurrently in teams, where not only the teams but also their individual members can be globally distributed. The tools should be able to cope with software projects that require more than a hundred concurrent developers.
The key role of these tools is in organising the development effort at the level of the software as a whole: the process of building and releasing products such as libraries and executables. The tools have very little to do with the design or the writing of the code. And while the suite does its best to help in the verifying the quality of the software, it by no means provides a complete testing framework.
There are three significant issues these tools do not address. The first is support for producing software distributions, unless you count mirroring as such. The second is quality assurance, such as keeping track of bugs and relating source code and bug records to each other.[1] The third issue is that there has not been any attempt to provide one integrated software configuration and development environment. This suite follows the unix-inspired philosophy where individual tools solve rather specific problems, and several independent tools are combined together to cope with larger problems. As a practical example, version management is not really dealt with by SRT at all--it expects you to use CVS for that. What is more, CVS is not hidden from the users in any way, quite the contrary. Keeping this in mind, repetitive tasks have been factored out into tools or other facilities in the suite. There is rarely any deep magic in them; their purpose is just to make the developers' life more convenient.
| [1] | There are fine free products that can handle these tasks, including GNATS. You may want to try to use them in your development process. |
| [1] | Typically the partitioning into packages follows naturally the domain decomposition of the software project itself. |
| [2] | In the context for which these tools are developed, the users almost always run the software directly from the releases. Hence the lack of support for creating distributions. |