Managing releases involves three factors: what you're releasing, who you're targeting, and why they want it.
What You're Releasing
You may be releasing something as small as a single patch to one component or something as large as the complete product. A full or complete release is of the entire product, usually to be installed on a fresh system or used to upgrade an existing system. A partial, module, update, or fractional release is some subset of product functionality usually designed to extend the capabilities of a base system, such as an optional module. A patch or update release is some subset of the product, that usually precisely replaces one or more existing components in a working installation that have known errors. In general, patch releases should not be used to add new functionality to an existing system.
The determination of a full, partial, or patch release can be quite fluid. You might be in the midst of planning a full release with two major milestones when a competitor makes a major announcement about one of their releases. Your plan then changes to preempt your competitor by converting the first milestone into a full release and the second milestone into a partial release. These factors and a host of others strongly influence a marketect's decision on what to release.
Full, partial, and patch releases are all subject to the same release processeshowever you've defined them. For example, most release processes require the team to do a virus scan before shipping any bits to a customer.
Who You're Targeting
You may be targeting internal users in an alpha release; external users, in a beta, limited, or general release. A limited, managed, or controlled release has been targeted to a specific set of customers. An example would be a patch release to customers who have a bug on a single hardware platform. A general release is intended for all of your customers.
Marketects and development teams often confuse who they're targeting with what they're releasing. "Who you're targeting" is about scope, whereas "what you're releasing" is about size. When a new virus is discovered , anti-virus vendors want to update their virus definition files quickly. What is being released is relatively small in size but large in scope. It might be referred to as a generally available update on the Web site of the anti-virus vendor.
I've found that many companies have trouble targeting their releases, mostly because they don't know enough about their customers. Let's say that you support Solaris and Windows XP and find a relatively easily fixed bug in the XP release. Unless you've kept track of which customers have Windows XP, you'll have to send out the announcement to all of them. It would be far more efficient, and far more compelling, if the announcement was only going to the people who should get the patch.
Why They Want It
Customer motivation can range from actively working against accepting and installing the release ("we can't install that patch in our production system ten days before the holiday shopping seasonit's too risky") to overwhelming your Web site because the demand is so great ("We must have it now "). Most releases fall into a middle ground, and usually the marketect has to use carrots (new features, improved performance, reduced bugs , greater reliability) and sticks (lack of support for discontinued platforms or releases, license agreement compliance) as a way of motivating the customer to accept and implement the release.
Choosing the right combination of carrots and sticks is one of the marketect's most complex tasks . For example, a new release is often made backward-compatible with a previous release. But should it be made backward-compatible with software that was released three years ago? Probably not, as the aggregate costs of such compatibility, including regression testing, operation verification, and associated support, can be enormous . Of course, losing important, major customers who may not be interested in upgrading their software to a new release can be just as risky, which makes keeping the installed base as current as possible a major job of the marketect. No matter how you keep track of these things, you're going to have "version skippers" and you're going to have to define the upgrade path from whatever version they've got to your current version, regardless of how painful the individual steps in the upgrade are.