O t h e r s t u f f
When you release a product `into the wild' you will need to know what you released, to whom
and when. This may seem trivial but in a large development environment it can be quite tricky.
Take for example a system where ten developers are working in parallel on a piece of code. When
you go to build and release a version of the system how do you know what changes have been
checked in ? When you release multiple versions of the same system to multiple customers and
they start reporting bugs six months later, how do you know which version the error occurs in ?
How do you know which version to upgrade them to, to resolve the issue?
Hopefully your version control system will have labelled each component of your code with a
unique identifier and when a customer contacts you, you can backtrack to that version of code by
identifying which version of the system they have.
Further your change control system will let you identify the changes made to that version of the
system so that you can identify what caused the problem and rectify it. Your change control system
should also record the version of the product that contains the fix and therefore you can upgrade
all customers to the correct version.
Typically you should track the following items for each release :
The version number of the release
The date of the release
The purpose of the release (maintenance, bug fix, testing etc.)
For each software component within the release:
the name and version number of the component
the date it was last modified
some kind of checksum which confirm the integrity of each module
Sample version control database :
(NB: A hash simply a mathematical function that takes the file as input and produces a unique number to identify
it. If even a tiny portion of the original changes the hash value will no longer be the same. The hashes in the table
above are represented as MD5 hashes in hexadecimal.)
Release controls should apply within development as well as outside. When the dev team releases
a product to the test team, it should follow a controlled process. This ensures that the teams are
working on the same builds of the product, that defects are being tracked and resolved against a
particular build and that there is a minimal lag in defect resolution.