Suggestions for Release 1.36.0

These suggestions are based on the 1.35.0 experience.

• Start work on the next release as soon as the current release ships.

• Give developers authority and responsibility to merge their libraries into the release branch right from the start.

• Provide developers better documentation on how they interact with the release procedures.

• The daily release snapshot and inspect has been very helpful. Continue running on an ongoing basis.

• The Release Manager is a bottleneck in that when he or she is busy with other work, release progress slows. Possible mitigation:
  • Have an assistant release manager who steps in when the release manager is busy.
  • Consider giving several people access to the machines that run trunk and release reporting.

• Refuse commits that would cause inspection errors. Inspection errors are time consuming, and slow release progress. The earlier they can be detected, the easier they will be to fix. Details need to be worked out. [This involves adding a new Subversion hook to the existing checks]

• Feed inspection errors into the regression reports, so that inspection problems are much more obvious. [Suggested by Doug Gregor; note that this becomes less important if we have the aforementioned Subversion hook]

• Feed trac bug reports into the regression reports, so that outstanding tickets for the release-in-process are more obvious.

• Make sure daily full inspection is run on both trunk and release. [Doug: if Subversion is doing these checks, does it matter?]

• Automatic install tests should be run on the daily snapshots to verify install isn't broken. Need to design way to automatically detect install failures, and report them to the list (perhaps by email). Two tests are needed, one for Windows, one for Linux. If those are working, the chance of failures on other platforms is much reduced. [Doug Gregor: in an ideal world, we would build+install, then perform testing against the installed tree]

• Recognize that infrastructure changes (new Boost.Build version, new testing procedures, new web site organization, new directory tree organization, etc.) have a history of being very disruptive and markedly slowing release progress.
  • Test and debug such changes on a branch before inflicting them on the trunk.
  • Make sure developers are educated as to the impact of such changes.

• Refine regression testing to make even more reliable and speedier. But move carefully, the testing is working far better and more reliably than in the past.

• Eliminate the smoke tests. They have not been a success, and now that the regular regression testing is more reliable, they are just a distraction.