1. Once an official baseline release of the product has been made, configuration management should be implemented in all circumstances.
2.ideally, configuration process by the developers, a transfer of the configuration management responsibility can be made from the development teams to a configuration management group.
3. In planning for software configuration management, well-respected software engineering expert watts Humphrey recommends that your plan include several key tasks.
4. Configuration control: Configuration control begins with the Establishment of a single baseline copy of the product source code.
5. A library for the master copy of the source code should be established, and managed check-in and check-out procedures should be instituted.
6. This single copy should be used for all subsequent builds.
7. All changes and updates are reflected in the build.
8. Interim checks are often established to prevent corruption of the master by requiring strict quality assurance and enforcing audit control procedures.
9. The use fo a single master for builds ensure that all changes are reflected in the latest version, and testing will account for such changes.
10. Change management: Change management and revision control refers in part to how modules that are checked in and out of the master source library are tracked.
11. Generally, a release has a major version id a minor version id and a build number associated with it.
12. It would be unwise to mix release 2.2 build 1104 with release 3.1 build 100.
13. Although it may have no bad side effects, you cannot be used.
14. It is better to regenerate all modules used in major release 3 as version 3.0 baseline code and have all builds, starting with the first one, an increment from that.
15. Mixing and matching among revisions is a sure way to court disaster.
16.Revisions: Revisions of the current working release of code will generally increment the build number.
17. In some places, a daily build-and-test process is done to ensure that all code worked on to that point will still compile and execute.
18. While these daily revisions generally increment the build number, cutovers to periodic code fixes or updates, such as quarterly maintenance release, will usually increment the minor version ID.
19. Changes that add significant functionality or upgrade the performance of an application will usually be done through a new release, complete with marketing collateral, advertising, and so on.
20. These changes generally increment the major version Id.
21.Deltas: Deltas can best be described as changed copies of the same code.
22. The difference that exists in one of the identical code modules when compared with the original is referred to as deltas.
23. The deltas between current and original are tracked for various reasons.
24. Applications often need to be generated for different platforms, and one platform may require something to be done slightly differently from the other platform.