Version and Release Management in Software Engineering
The process involved in version and release management are concerned with identifying and keeping track of the versions of a system. Versions managers devise procedures to ensure that versions of a system may be retrieved when required and are not accidentally changed by the development team. For products, version managers work with marketing staff and for custom systems with customers, to plan when new releases of a system should be created not distributed for deployment.
A system instance is an instance of a system which can be different from other instances in some way. There is a chance in which versions of the system may have different functionality, enhanced performance or repaired software faults. Some versions may be functionally equivalent but designed for different hardware or software configuration. Versions with only small differences are sometimes called variants.
Attention reader! Don’t stop learning now. Get hold of all the important CS Theory concepts for SDE interviews with the CS Theory Course at a student-friendly price and become industry ready.
A system release may be a version that’s distributed to customers. Each system release should either include new functionality or should be intended for a special hardware platform. There are normally many more versions of a system than release. Versions are created with an organization for internal development or testing and are not intended for release to customers.
Version Identification :
To create a specific version of a system, you’ve got to specify the versions of the system components that ought to be included in it. In a large software system, there are hundreds to software components, each of which may exist in several different versions.
There must therefore be an unambiguous way to identify each component version to ensure that the right components are included in the system. Three basic techniques are used for components version identification :
- Version Numbering :
In version numbering scheme, a version number is added to the components or system name. If the first version is called 1.0, subsequent versions are 1.1, 1.2 and so on. At some stage, a new release is created (release 2.0) and process start again at version 2.1.The scheme is linear, based on the assumption that system versions are created in sequence. Most version management tools such as RCS and CVS support this approach to version identification.
- Attribute Based Identification :
If each version is identified by a unique set of attributes, it is easy to add new versions, that are derived from any of existing versions. These are identified using unique set of attribute values. They share most of those values with their parent version so relationships between versions are maintained. You can retrieve specific versions by specifying attribute values required. Functions on attributes support queries like ‘the last created version’ or ‘the version created between given dates’. Attribute-based identification may be implemented directly by version management system, with component attributes maintained in a system database. Alternatively, attribute identification system may be built as a layer on top of a hidden version-numbering scheme.
- Change Oriented Identification :
Each component is known as as in attribute-based identification but is additionally related to one or more change requests. That is, it is assumed that each version of component has been created in response to one or more change requests. Component version is identified by set of change requests that apply to components.