Product Development - Rolling out the patch

The previous post had thoughts on what are some of the conditions under which a software patch is typically required. Once the decision has been made to make a patch, there are a set of activities that are needed to be done. A patch typically is a miniature version of a complete product development cycle, not with all the activities, but certainly having many of the steps that one needs to carry out in the typical cycle. What are some of these steps that are needed to be done ?
- Decide on which of the fixes need to make it to the patch: When preparing a patch, there is always the temptation to fix all the issues that have been found after the release. However, beware of feature creep. You should only include fixes on the patch that are deemed critical. Putting other fixes means that the time period for the patch becomes longer, it means that QE needs to out more effort to test the patch, and so on.
- Make sure that all the teams are signed up for this patch. For a moderately sized software company, there will be multiple teams (with their specialized functions) that are needed to make the patch. These include the development team, quality testing team, configuration team that is responsible for the installer and release, localization team (if there are multiple languages involved - this is another decision point, whether the patch needs to be rolled out for all languages), marketing teams to ensure that patch publicity plans have been rolled out, web teams (if the company website is maintained by another team, they need to involved so that they can schedule the patch rollout date into their plans)
- Decide the schedule of the patch. Even though this is an abbreviated release, it will still take time, and the further this time pushes into the schedule for the next release, the more impact that this patch will have in terms of creating problems for the next release.
- Decide on branching strategies. Typically teams need to make sure that the source code repository has a proper branch created to handle the new branch for the patch. In most cases, the entire team will not be involved in making the patch, and so the work being done by the rest of the team for the new version will be on the main branch, and the work being done by the engineers working on the patch will be on the separate branch. A strategy also needs to ensure that the defects being fixed on the patch will be integrated with the main branch once the work on the patch is done.
- At the time the work on the patch is being carried out, if the patch is due to some major customer issues or some security issues, then the marketing and management of the team need to decide whether to release news of an upcoming patch. Typically, news of patches are not released earlier, but sometimes such news can help in calming down customers who would otherwise be worried.
- Development work for the fixes that go into the patch will need to be done. This typically involves a thorough engineering investigation into the issues that need to be fixed as well as working with outside partners if the issues needs such cooperation
- Once the fixes are made, they need to be thoroughly tested by the QE team on the different platforms on which the software is supported
- Now the patch is ready, and needs to be rolled out through the different media that can be used. The patch can be mentioned on the company web site, on the product page, in customer support forums, to product users directly if there is the ability to send software users a notification inside the product, via email to all the registered users, show as an update to users if the app has the ability to do an automatic check for updates.

The next post will talk about minor (dot) releases and the difference between a patch and a dot release.