Release Identification


Unlike component identification, which may or may not be publicly exposed, release identification concerns the manner in which a release is identified to a customer. The full identification consists of the product name (see Chapter 9) and versioning information that captures the appropriate product revisions and variations. The goal is to get all of the necessary information in as few names and identifiers as possible, which helps improve overall efficiency.

Over the years , I've learned that there is no single, universal algorithm for creating release identifiers. Moreover, you need slightly different algorithms for what you're releasing and who you're targeting. With these caveats in mind, here are algorithms that have worked well for me and proven to be considerably more useful than the seemingly arbitrary identification schemes used by many vendors .

Full or Complete Releases

Regardless of who you're targeting, full releases are best identified using

  • The name of the product

  • The four-digit tuple of x.y.z.build to capture revision information

  • An arbitrary number of variation identifiers pursuant to the needs of the product

The parts of the four-digit tuple x.y.z.build, are defined in Table 15-2. Note that this scheme takes advantage of the natural linear ordering of revisions.

It's usually best for marketing to promote only the major and minor identifiers to customers. In other words, when customers are told they'll be receiving version 3.4 of the product, they might really be receiving version 3.4.2.129 or 3.4.7.13. The primary motivation for this is the expense of trying to manage the full tuple in promotional materials, license agreements, sales collateral , and so forth. You don't want to incur the expense of reprinting all these materials because of a maintenance release.

By definition, a full release distributed to an existing customer is a complete upgrade. You'll find that customer satisfaction is improved when you only modify components that absolutely must be modified, especially in the case of a dot release.

Some people recommend including the target of the distribution in this scheme by inserting an appropriate identifier. For example, you might have A for an alpha/internal release, RC for a release candidate sent to QA, MR for a managed release, and GA for a general release, all inserted to the right of the y or z designator ("SuperDraw 4.5A"). I prefer not to do this because it makes the overall naming convention unnecessarily complex and because it mixes what is being released with who is being targeted . I've also had situations in which a release originally intended only as an alpha was later distributed to a trusted external customer. This change in scope invalidated the release identifier and thereby limited its usefulness .

Table 15-2. Release Tuple Definitions

Tuple

Definition

x

A major release. One motivation to increment the major release number is when there is some extensive , customer-visible architectural or feature change. These changes, in turn , must be defined and agreed upon by the marketect. Consider a system that manages very large databases. In such a system you might define a major release as any release that

  • Changed the structure of these databases because of the rather severe impact upgrading the system had on your customers;

  • Modified the published API in a way that makes it incompatible with previous versions;

  • Removed functionality (yes, a good marketect will remove unwanted functionality); or,

  • Added substantial new functionality, such as support for a new operating system.

In systems that rely on multiple components, incrementing x on one might mean incrementing x on the other. An example is a client server system, in which clients at release x.*.* are guaranteed to work with servers x.*.* and x 1 .*.*, but not servers x +1 .*.*.

x can also be incremented for purely business reasons. For example, a customer's support contract might state that that their software will be supported for 18 months after the next major release. By incrementing x, you put the customer on a forced path to upgrade (one of the sticks I mentioned earlier). In one company I worked at, we designated our first release of a major enterprise-class system as 5.0, to both build on a legacy of previous releases of a related product and to help us avoid the concerns that many IT administrators have regarding a 1.0 release of the software.

Most marketects should establish strong goals to distribute major releases to all customers as quickly as possible. If it is a major release, treat it as such.

y

A minor release, usually associated with desirable features or other improvements. The minor release number is incremented when marketing deems it justified by the set of features in the release. The decision to increment x or y can seem arbitrary. The marketect should define the events that trigger any increments . (It is easier to define the trigger associated with x than with y.).

z

A maintenance or " dot " release. Maintenance releases are made available to all customers affected by the contents of the release. Any given dot release should be compatible with other dot releases that share the same major and minor release numbers .

build

The specific build number associated with the product. For compiled languages, it is easy to compute the build number. For interpreted languages, the build number can be created by a simple program that labels a fully checked-in code base.

The build number is rarely presented to the customer unless needed for precise identification purposes, usually in relation to technical support. The build number may be optional if the main component is an aggregate of subcomponents. Suppose a product comprises two subproducts : one, release 1.3.2.29, the other release 3.6.2.19. It might be acceptable to identify your release as 3.4.0.0 or anything else that indicates the composition.

Partial Releases

Determining the identification scheme for a partial release mostly depends on marketing factors. If the component or artifact can be purchased separately or as an option in the main distribution, it is usually best to have it evolve under its own x.y.z.build identification scheme according to the guidelines given in the previous section. Naming consistency makes it easy for customers to build a mental model of the various optional components. It also makes it easier to construct an overall list of available products.

Partial releases that are not sold separately, such as updated anti-virus files, and not expected to be revised in the future, don't have the same complexities associated with a naming convention that revisions do. In this case, partial releases simply need a unique identifier. For most products a specially defined name and a date are usually sufficient.

A key issue in creating partial releases is managing the dependencies between their components or functionality and those of the main product. These dependencies may be captured through rules that govern release identifiers or through the design of the architecture, as described later in this chapter. As an example of the rules approach, you might require that every release of a component at version x.y be compatible with every version of the main system designated x.y n , where y n is greater than or equal to y. Thus, "SuperDraw Enhanced Rendering Tool 4.5" would be compatible with "SuperDraw 4.5," "SuperDraw 4.6," and so forth. Rules won't do you or your customers any good if you fail to follow them: If SuperDraw were to go through a major upgrade and be released as "SuperDraw 5.0," you would have to modify the release identifier of the enhanced rendering tool to match, even if the code didn't change. While this may seem like busy work, it will save you and your customers a lot of pain (and license agreements may require this).

Patch Releases

Recall that a patch release is some subset of the product that usually precisely replaces one or more existing components in a working installation that has known errors. Identifying patch releases represents special challenges. Everyone involved usually has a strong opinion on how to identify a patch release, everyone thinks that their way is the best way, and everyone feels like arguing over each point for an endless amount of time! Many poor choices can be made when identifying patch releases. This section provides guidance on easily creating a sensible patch release identification scheme. Patch releases are always associated with something in use, which means that they deal with a customer in a potentially stressful situation. Moreover, the team that creates the patch may not be the team that created the system and so may not be familiar with previous release identification schemes.

Because patches are highly dependent on an existing product, it is usually convenient to refer to that product in the patch identifier. At the same time, you don't want to adopt the x.y.z.build numbering convention because patches are rarely revised unless a serious mistake was made in the QA or release process. More important, the linear ordering associated with revisions implies that everything included in the previous release is included in the next highest release unless specifically stated otherwise . Thus, we expect that version 4.5 of our favorite compiler includes and extends the functionality in versions 4.2, 4.3, and 4.4. This is not necessarily true with patch releases. A given patch may or may not include the modifications of a previous patch. Patches are not cumulative unless designed as such.

Patches are often associated with emotionally charged events or bugs that take on a life of their own. Since some aspect of these events or bugs usually becomes associated with the patch, I recommend leveraging this by referring to patches by name and possibly by date. The net result is patch names of the form productx .y{.z{.build}}patch name. Note that the maintenance release and build number are optional in this naming convention, which in practice allows customers to easily identify the patch they need. The external, customer- facing name might be something like "SuperDraw 4.5 Repaginate Long Documents patch," which means that this patch can be applied to any SuperDraw 4.5.* system. If the patch is focused on a specific dot release, you refer to it in this scheme as "SuperDraw 4.5.2 Repaginate Long Documents patch."

Especially complex products may call out those areas affected by the patch, primarily because it makes it easier for customers to identify which patches they want to download from a self-service technical support Web site. Let's say that you have a client/server system with an optional workflow module. You might augment the naming convention to be productx.y{.z{.build}}product areapatch name, as in "SuperDraw 4.5 Repaginate Long Documents Server patch" or "SuperDraw 4.5 E-mail Client Notification Workflow patch."

Patches that are dependent on other patches can call out those dependencies via documentation. If a large number of patches are associated with a product, I recommend collecting them all in a maintenance release. If this isn't possible, another approach is a service pack that does the same thing. Make certain your documentation is clear on whether or not service packs are cumulative.

Note that not everyone agrees with naming patches. Imagine that your patch has an error (yes, it happens). This means that it needs to be versioned, and versions are best handled through numbering. You might version the patch but not include the version identifier unless it's absolutely needed. Thus, your patch would be in the form productx.y{.z{.build}}patch name.patch version. If you have a problem with the first version of "SuperDraw 4.5 Repaginate Long Documents Server patch," you can release a second version called "SuperDraw 4.5 Repaginate Long Documents Server patch, version 2." However you choose to resolve this, do not impose an arbitrary limit on the naming, because you'll eventually run into a situation where the limit is exceeded.

Very sophisticated architectures are smart enough to package patches together, tracking what is installed and not installed. Some companies do this in their software and allow automatic updates (think of anti-virus software as a simple example). Other companies (such as ManageSoft) do this on behalf of corporate administrators, taking snapshots of the software on various desktops.

Let's assume that you want to extend your architecture to include patch management. If so, it will need to be smart enough to understand what is and is not installed. It will need some mechanism for communicating with a remote server, preferably over the Internet, to obtain updates. It should be able to detect if prerequisites are available and if not install them. It needs to be able to determine that an automatic update was installed correctlyit didn't break the system or any settingsand roll back the change if something is wrong. These are very complex requirements, which is why I don't generally recommend this approach.

Bug Fixes Don't Have to Be Free

When bug fixes are not included as part of the license, the marketect must decide when to fix them. Sometimes the right choice is to fix them as a way to build good will with a customer. Sometimes the right choice is to charge for the fix, which can also build good will with a customer.

I once had a customer with an extremely urgent request to fix a bug on an unsupported product. Specifically, they had a perpetual license to use the product, but the version they had installed was no longer supported. In a very real sense, they brought this problem on themselves because they had failed to upgrade their system over the course of several releases. When they contacted us to fix the bug, I originally said "No, if they want the bug fix they can upgrade."

As the saying goes, "Money talks ," and my original No turned to Yes once I was able to negotiate a substantial fee for the fix. My team hustled and fixed the bug in record time (even I was a bit surprised at how quick they were!). The customer was so impressed with this service that they subsequently executed the major upgrades they had delayed far too long.

Variations

Variations, like patches, don't have monotonically increasing revision numbers. Naming them and inserting or appending the name into the overall identification string in a way that makes sense is the best way to handle them. For example, suppose that our SuperDraw client/server system supports Linux and Solaris. The binaries for these operating systems are functionally equivalent but physically different. Thus, you might call a full release of version 4.5 "SuperDraw 4.5 for Linux" and "SuperDraw 4.5 for Solaris." If you require a patch to this release for Linux, you call it the "SuperDraw 4.5 e-mail Notification Workflow Patch for Linux."

Things become more complex when the system or component supports multiple variations, usually associated with portability, internationalization, or performance characteristics. Suppose that SuperDraw supports six languages and has two performance options: single- (default) and multiple-CPU. Here are some of the ways this might be handled.

  • "SuperDraw 4.5, German Language for Linux" for a full release of the single-CPU version

  • "SuperDraw 4.5, German Language for Linux, multi-CPU," for a full release of the multi-CPU version

  • "SuperDraw 4.5 email Notification Workflow Patch, German language, for Linux"

As a general rule, the more options, the more complex the name. I consider this a good thing because customers don't deal with these names every day and they often have trouble clearly remembering what they want or need. Verbosity ensures that they are getting the right artifact.



Beyond Software Architecture[c] Creating and Sustaining Winning Solutions
Beyond Software Architecture[c] Creating and Sustaining Winning Solutions
ISBN: 201775948
EAN: N/A
Year: 2005
Pages: 202

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net