Even with the version numbers sorted out in the manner described, this can be a painful way to develop software. In this article I've described big bang releases — perhaps a single major release is made every year. In between these releases the main trunk of the codebase is allowed to fall short of release quality: things break and it's only when we create a release branch that we undertake to fix them. There's too much dependency on a team of manual testers to shake out problems, with the effect that the software developers have neglected this duty.

Meanwhile, the sales and marketing team are busily hyping the next release. It's to be announced at an international trade show: How's that for an immovable deadline ^[4]?

Customers must be persuaded to upgrade but some fail to be excited by the new 2.0 features, seeing instead a bunch of changes they don't particularly want. Instead they'd like to continue with version 1.0, which is the version they purchased — though naturally they demand support and bug-fixes.

Eventually the codebase spreads over several branches which have become increasingly laden with patches merged in all directions. The version control system can handle it but can the developers? Although we have several active versions of the software, it's moving irrevocably into maintenance mode.

It seems to me that the emphasis on version numbers and features is wrong, and may indeed take some of the blame for this grim situation. It's wrong to risk the stability of the main development trunk and reserve branches for stable code. Instead we should aim for a pristine trunk and use branches for work-in-progress and experiments, so that at any point during development, the tip of the trunk represents the best code we have.

It's also wrong to create an environment in which customers cling to old versions of software. Instead, we should consider upgrades from the outset, and allow our software to migrate softly from version to version.