Best practices for source control and bug fixes

Question

If we need to issue a bug patch that does not include current development that has been committed, or any changes from their current version, what should be done to make the process safer and with lower overhead?

We are currently using Subversion for our source control in a small (3 developers) team primarily developing in Visual Studio 2008. We anticipate that the team may group to 8 developers over the next year, and for any previous release support to become more complicated. While most customers are on the current release, some are further behind.

Answer 1

Source control can handle this pretty easily, and was designed for this.

When you reach the stabilization period of your release a branch should be done. It is important that you do not start any work on the next release before this is done.

Any bug fixes for that release should be done in that branch. This prevents new code from an upcoming release from polluting the bug fix. Once the bug fix is done then you can merge that change down to the trunk, and any other releases as necessary.

Don't forget to put the bug number in the comment, as this will make keeping track of commits easier.