First of all, there is the release from the technical or developer's viewpoint. In this instance, a release is both a set of programs, files, directories and links, and the process by which they are made available to the client workstations and user community. Technically, a release is the set of things delivered via system packs and the process of taking a source tree and building these packs, as well as installing and updating client workstations.
Secondly, there is the release according to the user community. One could argue that many users view a release as a mystical event that changes the environment in which they do their work. Or, as sometimes is the case, a release is a enormous beast that prevents them from doing what they need to do because it can't be changed. More practically, for users a release pretty much *is* the work environment.
Finally, there is the release from the historical release teams' viewpoint. The release team views a release as a co-ordination effort that takes a list of changes to the computing environment, and shepards them from conception through implementation to delivery and support. In some ways, the release team spans the divide between the technical definition of a release and the customer's point of view.
For example, technically speaking, olh is not in the release because the actual programs resize in a locker instead of on the srvd. However, most users consider help part of the work environment and therefore the release team expands the scope of a release to ensure that help continues to work. In the same way, the release team will view a release in such a way as to consider issues such as where X lockers mount, or how a change in operating system will affect third party software installed in lockers.
So, back to the original question: What is a release anyway? A release is the effort which co-ordinates changes to the computing environment and a process by which changes are made. Because of the current implementation, a release must include all changes made to software currently delivered via the system packs, but it (should) also include(s) changes that affect other systems or programs and require co-ordination across Teams and Processes.
Dorothy Bowe <dot@MIT.EDU>