take the latest version of the system (with the bug fix).
The latest version had seldom been tested against that customer's configuration parameters, and it usually took weeks for the new release to stabilise.
Like most such processes, this had grown in a higgledy-piggledy fashion over the years in to the unholy mess it was then in. No big bang fixes were possible and it has been a slow and steady process of enhancements that have taken them to a much more controlled environment today. Migrating to a single SCM tool across all platforms was an early step. Separate build and test environments for testing brought major advantages. Branching to support older releases was also beneficial. It's still a work in progress!
Making a system easy to release is very much a holistic “thing” - you need to look at the whole lifecycle of the development. Plan it, up front and throughout; adjust your processes and use appropriate patterns. Practice releasing regularly, and even if iterative and agile methodologies are not possible in your particular organisation, steal as many practices as appropriate and apply them.
If you are assigned to look after releases in your organisation, start working back through the whole process looking for places that you can influence things to make your job easier. Bad decisions early in the process can make releasing a nightmare - don't accept them. Identify the problems, point out the ramifications, and work with the appropriate people to improve those areas.
Software Release Methodology ; by Michael E. Bays; Prentice-Hall PTR 1999
Release Management,The Super Discipline ; by Mario E. Moreira; CM Crossroads Journal, November 2002 (Vol. 1, No. 11)
Trustworthy Computing ; by Craig Mundie; Microsoft Whitepaper, October 2003
Lean Software Development: An Agile Toolkit ; by Mary and Tom Poppendieck; Addison-Wesley 2003 (see http://www.poppendieck.com)
"Software Development Productivity / Make More Money!" ; presentation by Mary Poppendieck
The XP2002 Conference ; summary write-up by Martin Fowler at < http://www.martinfowler.com/articles/xp2002.html#N100FC
Software by Numbers – Low Risk, High Return Development ; by Mark Denne and Jane Cleland-Huang; Prentice Hall PTR, 2004
Principles of Lean Thinking ; by Mary Poppendieck; 2002 Conference on Object-Oriented Programming Systems, Languages, and Appplications (OOPSLA 2002); Seattle, WA, November 2002
Lean Programming ; by Mary Poppendieck; Software Development Magazine , May-June 2001 (Vol. 9, No. 5 and 6 -- see full article at http://www.poppendieck.com/lean.htm)
Agile Configuration Management Environments ; by Brad Appleton;Chicago Software Process Improvement Network (CSPIN) presentation, March 2004
Joel on Software - June 2004 comments (see http://www.joelonsoftware.com/items/2004/06/17.html )
How Microsoft Lost the API War ; Joel Spolsky, from Joel on Software - June 2004 (see http://www.joelonsoftware.com/articles/APIWar.html)
Container-based SCM and Inter-File Branching by Laura Wingerd; BCS CMSG 2003 Conference (see http://www.bcs-cmsg.org.uk/conference/2003/abstracts.shtml#Wingerd )
Software Configuration Management Patterns: Effective Teamwork, Practical Integration ; by Stephen P. Berczuk and Brad Appleton; Addison-Wesley, November 2002
Build Management for an Agile Team by Steve Konieczka, et.al.; CM Crossroads Journal, October 2003 (Vol. 2, No. 10)
Codeline Merging and Locking: Continuous Updates and Two-Phased Commits , by Brad Appleton, Steve Konieczka and Steve Berczuk; CM Crossroads Journal, November
2003 (Vol. 2, No. 11)
Agile Change Management: From First Principles to Best Practices ; by Brad Appleton, Steve Berczuk and Steve Konieczka; CM Crossroads Journal, August 2003 (Vol. 2, No. 8)
SCM Patterns: Building on ‘Task-Level Commit’ ; by Austin Hastings; CM Crossroads Journal, June 2004 (Vol 3. No. 6)
Can We Ship Yet ?; by Gareth Rees; 2001 Perforce