Lessons learnt from release 4.2: What will we do differently this time?

This page outlines the steps we intend to take to avoid some of the problems which arose during the release of CCP4 4.2. The problems themselves are described on a separate page.

• Discuss well in advance with contributors (both local and external) regarding what will be provided for the next release - particularly with regard to components which require porting, or which have new dependencies not currently configured in the suite, or which need major updates to CCP4i.
• It enables us to set realistic deadlines for the release, and makes it easier to prioritise development work, anticipate potential problems, perform testing and so on
• Issues with new dependencies can be addressed (e.g. Python)
• Major updates to CCP4i can be made in good time

• The only code changes we will accept after the submission deadline for release has passed are bug fixes against specific bug reports. No developmental changes will be accepted i.e. there will be a code freeze.
• In our experience late addition of new features (so-called ``feature creep'') are generally insufficiently thought-out and often cause chaos. If the new feature is really important then it should have been included earlier.
• New features negate any earlier testing, which has to be repeated (wasted effort)
• Halting development means that all effort can be focused on bringing the suite up to scratch, minimising the release time and cutting down on the lock-up of effort.

• Better communication with the external developers
• Early on, inform contributors of changes to the core suite which might impact on their software.
• Keep external developers informed of the release status via the Developers Bulletin Board (ccp-dev) and dedicated webpages.

• Better communication with the test sites
• To ensure that they have the most up-to-date test version, and that bugs reported by them are properly tracked and fixed.