Release Taxonomy

Release Taxonomy

Copyright 1991-2007, Sun Microsystems, Inc

Policy Synopsis

A Release Taxonomy sets forth rules of the road that will help Sun deliver the customer an understandable progression of releases without presenting impediments to the delivery of large amounts of innovation in hardware and software. This memo establishes a logical guide for the formation of staged releases as proposed by the SSBT, It may not be practical to implement all aspects of the proposal immediately; thus, the memo describes a goal to be attained through a series of near-term compromises.

This memo is based on work of the Software Development Process Team, plus inputs from members of the Solaris Business Team and many others throughout Sun.

This memo has benefited from inputs by many reviewers, and especially from extensive comments by Randy K and Andy H.

Contents

• Introduction and Scope
• The Release Naming Scheme
• Further Definitions and Concepts
• Reference Realizations
• Specific Realizations
• Table 0: Content Rules for Release Realizations
• Table 1: First Customer Ship Availability of Realizations
• Table 2: Upgrade Rules for Reference Realizations
• Table 3: Upgrade Rules for Specific Realizations

Overview

Operating System Release Taxonomy

Introduction and Scope

This memo discusses mechanisms and policies for operating system and hardware deliveries via Sun's traditional direct sales channel. Other channels may require a different (in many ways more restrictive) set of guidelines for generating releases. The presentation dwells on issues of concern primarily to the operating system (and other software close to the hardware). The discussions apply, albeit in simpler form, to all other areas of software.

The presentation is somewhat heavy at times. It has been difficult to derive rules of the road that are both reasonable and yet easy to describe in all their ramifications. Thus, the presentation attempts to say things in three ways: mathematical notation, prose and tables. Hopefully, the reader will find that points not clear in one form will be better understood in another, and that it is not necessary to understand all forms (especially the math!).

All rules presented in this memo are subject to variances based on business requirements. Thus, it is assumed that a responsible body (the Q team) will oversee the application of the rules and granting of variances. However, extensive use of variances will suggest that something is broken, so the reader is encouraged to assess the rules by how well they serve the stated goals and by how (in)frequently they are likely to need variances.

A summary of the major concepts can be obtained by reading sections 1, 2 and 3 coupled with careful study of Table 0 and Table 1.

The Release Naming Scheme

The term release level will be used to designate release content as an abstraction and the term realization will be used to designate the actual bits for a particular set of machine architectures and packages. The importance of maintaining a distinction between the abstraction of content and the realizations of content stems from the need to paint an understandable progression of software content for Sun's customers while maintaining flexibility in the delivery of new products.

The major goals are:

• any perceived differences between realizations of the same release level must be obvious and direct consequences of differences in the machine implementations, peripherals supported or packaging choice.
• the sequence of realizations must avoid surprises or anomalies with respect to the hardware products supported, software features present, and bugs fixed or introduced.
• the overall scheme must make sense to customers, end-users, ISVs, OEMs, sales and support.
• timing of realizations must take into account a substantial proportion of the installed base of hardware, software, OEM and 3rd party products.
• timing of realizations must take into account a substantial proportion of Sun's shipping hardware products.
• there must be a vehicle for timely delivery of new software functionality, hardware platforms and peripherals.

These goals are often at odds with one another and will always require careful management. A release naming scheme will not eliminate all problems, but can serve to provide the element of rationality within a framework for delivering a rich, complex and fast-growing product line.

A release realization name takes the form:

architecture [ / flavors ]

product  major . minor [ . micro ]  package

For a given realization, architecture indicates what set of application and implementation architectures the realization runs on and the optional qualifier flavors indicates that the realization runs on some limited set of configurations.

product names the base product and major.minor[.micro] names the release level.

These two components completely determine the content (or functionality) of the release as an abstract entity. package indicates the precise form the realization takes. For example,

Sun-3 OS 5.2.1 ½"

names a realization of release level 5.2.1 of the operating system that runs on any Sun-3 and appears on half-inch tape.

Note that there can be many realizations of the same release level of a given product, and the rationale for those realizations must somehow be encoded in the other components of the name, primarily flavors and package.

This is a problem that will require ongoing scrutiny as release plans evolve, and the details on the form of the remainder of the name have been left vague on the assumption that the product team will do the right thing with it. Some of the considerations on the use of architecture, flavors and package components should become apparent on further reading.

Further Definitions and Concepts

Release Families

A minor release family is the sequence of micro releases having the same minor release prefix. 

A major release family is the sequence of minor and micro releases having the same major release prefix.

A new release level or new realization of an existing release level is said to be against or based on an existing release level if it is derived from that release level by the rules and guidelines in this memo.

Release Realizations

The set of realizations scheduled for a release level is well-defined and changes slowly over time to incorporate new (or obsolete old) architectures, machines, configurations and packages (by rules outlined in subsequent sections). This set is referred to as the reference realizations. 

No new release level will ship without a full set of reference realizations. This is because the reference realizations serve as a standard by which other realizations are measured and because the reference realizations form the core set of realizations needed before a release level can be the "preferred choice" in sales situations or strongly recommended for upgrades of existing sites.

Additions to the set of reference realizations for a given release level are determined by a set of rules intended to control the amount and type of risk appropriate for major, minor and micro release levels. In general, new entrants to the set of reference realizations must prove that they are ready by first appearing in a specific realization (see below). However, there is some flexibility to this rule to allow for business requirements and scheduling realities.

Strictly speaking, the set of reference realizations does not grow as a superset with increasing release level or with passing time, but it should tend to do so.

Specific Realizations

A specific realization is a port of a shipping release level targeted for a limited set of new hardware[1]  products; platform realization and platform specific realization are common alternate terms with the same meaning. A specific realization never creates a new release level. A specific realization introduces new hardware. Typically, new release levels for the reference realizations will require a new specific realization for those release levels until the specific realization is consolidated into the reference realizations. 

The set of files that may be different between a specific realization and a corresponding reference realization into which it will eventually be subsumed is roughly defined by the contents of /usr/kvm[2].

Other rules governing specific realizations (presented in the sections that follow) are intended to insure that they appear to be part of the reference realization in every possible respect.

Specific realizations are delivered as a package that upgrades an already existing reference realization, or as a complete installation package. This will be determined by the technical and business requirements.

In the naming scheme, the product and release level components of the specific realization name are the same as the corresponding reference realization. The remaining components of the name differentiate it from the reference realization as appropriate. For example, specific realizations are identified by the flavors component; thus,

Sun-3x/555 OS 5.2.1 ½"

names a specific realization of release level 5.2.1 of the operating system that runs on Sun-3x model 555's and appears on half-inch tape.

[1] For convenience and economy, the term hardware covers all possible variability in architectures, machines, configurations and packages. 

[2] The files that may be different are those that are not shared, as long as there is no violation of interfaces. The precise specification of file sharing is available as part of the SunInstall design and implementation documents.

Limiting the Variables

The most powerful tool for control of release realization schedule is control of content. Thus, the rules presented in this memo are intended in part to regulate content of individual realizations consistently with overall goals. In simplest form, the rule is: 

New software on stable hardware.

New hardware on stable software.

However, control must go beyond these rules. For example:

• Software deliverables must be required to pass unit tests for quality and performance before they are integrated into the release. Software that is not ready to meet the unit test criteria must be delayed to a later release level.
• The number of hardware deliverables in a realization must be determined by the overall Beta testing requirements and the cumulative schedule risk. Since hardware is often affected by outside factors (such as component availability) and can have significant short-term implications for revenue, it will often make sense to limit risk by partitioning the realizations carefully.
• Even when dealing with known entities, such as bug fixes and hardware already shipping on a specific realization, careful assessments must be made of the overall risk of many changes in a single realization.

At the other end of the spectrum, the number of realizations supported in the field and the number of realizations under development are also measures of complexity and risk that must be controlled. This issue is addressed by the product Q team.

Release Binding

Release binding is the point at which deliverables have been identified for inclusion in a new release level of a product, and the process of loading the train starts. No new deliverables can be accepted after this point, and the set of reference realizations is fixed for the release.

Following release binding, and preceding Beta, is a closely scheduled period of integration(s), build(s) and test(s).

Beta

At Beta, a release must meet all content, quality and performance goals set for FCS, as measured by internal testing procedures. In other words, the engineering of the product is complete. The Beta period is intended to test and improve the ability of the remainder of the organization to manufacture, deliver, support, ... the new release level of the product in the field.

Patches, Upgrades and Installs

A patch is a limited set of files and changes to files, along with scripts to aid in installation of the new files and changes within the context of an existing installed system or network. The individual patches can be installed selectively, as long as precedence requirements are met.

A true upgrade applies all necessary changes to bring an existing installed system or network to the same state it would be in after a full installation of the release realization being used to do the upgrade. The installation tape used for the upgrade will contain scripts to aid in the upgrade process.

Patches and true upgrades occur "in place"; that is, existing user files and administrative data are preserved without requiring backup and restoration.

An install overwrites an existing installed system, if present. Existing user files and administrative data must be backed up, restored, and possibly converted to carry over into the new release.

When discussing compatibility properties from the customer or end-user view-point, the term upgrade is somewhat ambiguous: the term "upgrade" may be used to describe an install of a higher release level over an existing lower level release. When a true upgrade could have been done, an install will achieve equivalent results at higher cost; however, there are situations in which this could represent a set-back. This memo attempts to carefully differentiate these situations.

Reference Realizations

This section is, for the most part, summarized by the columns labeled Reference Realizations in Table 0. 

In the discussions that follow, the concept of containment ([must contain]) relates to the "visible" aspects of software features or hardware support, not to their implementation. The function ReleaseDate( ) yields the release binding date for a release; if only the release level is specified, the date is for the set of reference realizations.

Major Releases

Basics

X.0 is a major release
X.0 [is equivalent to] X.0.0

Major releases always have a 0 as the minor release number. For convenience in discussions, the 0th micro release against a major release is equivalent to the major release.

X.0 [must contain] (X-1).Y.A [when] ReleaseDate(X.0) >= ReleaseDate((X-1).Y.A)

A major release must contain all generic software features in a minor or micro release against the previous major release whenever the major release binding date is later than or the same as that minor or micro release binding date.

Furthermore, a major release must contain all patches whose availability date is earlier than or the same as the release binding date.

These rules do not apply to obsolescence.

Planning Release Content

A major release introduces or changes significant software functionality and architectural features. It includes bug fixes that were in previous releases and may include additional bug fixes. Although every attempt is made to provide compatibility for existing applications, some applications may have to be re-released to work at all, and some will have to be re-released to realize the same (or better) performance and integration. 

A major release may require an install (as opposed to a true upgrade). The administrator will be given tools and instructions for preserving or, where necessary and possible, converting existing "user" files.

New hardware can be added to a major release only if it has FCSed on a specific realization before the major release binding date. Note that the time from release binding to FCS for a major release will be much longer than for a minor or micro release.

Scheduling the Release

Major releases are not scheduled to occur on a regular basis. For the operating system, this probably means a major release less frequently than once every two years. 

The schedule from release binding to FCS for a major release is not as proscribed as a minor or micro release. The schedule for a major release can only be set as a goal until the release has attained Alpha quality, at which point status and plans are reviewed to establish a committed plan.

Lifetime

The effective lifetime of a major release is long when one considers that it will be used as the basis for many minor and micro releases. The lifetime of the initial release of the family (X.0) is in other respects the same as that of a minor release. 

Minor, micro and patch releases from the previous major release family may continue availability until deemed no longer necessary. This is because a major release cannot be the preferred shipment until enough unbundled and 3rd party products are available to allow substantial acceptance of the release in the customer base. Supporting multiple major release families will have high logistic and strategic costs; therefore, "hold-out" hardware, unbundled and 3rd party products may have to be pressured into move forward to the new major release family.

Obsolescence

A major release is a prime opportunity to obsolete software programs or interfaces that are deemed no longer worth maintaining or have been replaced by new programs or interfaces. Major releases can also be used to obsolete hardware support. Obsolescence is allowed only with suitable warning and must include a phase-out or transition period. 

Minor Releases

Basics

X.Y [when Y > 0 ] [is defined to be] a minor release
X.Y [is equivalent to] X.Y.0

Strictly speaking, minor releases start numbering from 1; however, since a major release can have minor release content, some discussions will implicitly or explicitly include X.0 as a minor release.

For convenience in discussions, the 0th micro release against a minor release is equivalent to the minor release.

X.Y [must contain] X.Y-1 [when] Y >= 1
X.Y [must contain] X.Y-1.A [when] Y >= 1 [and] ReleaseDate(X.Y) >= ReleaseDate(X.(Y-1).A)
X.Y [must contain] X-1.Z.A [when] Z >= 0 [and] A >= 0, [and] ReleaseDate(X.Y) >= ReleaseDate(X-1.Z.A)

A minor release must contain all generic software features in a previous minor release against the same major release.

A minor release must contain all generic software features in a micro release against the previous minor release whenever the minor release binding date is later than or the same as that micro release binding date.

A minor release must contain all generic software features in a minor or micro release against the previous major release whenever the minor release binding date is later than or the same as that minor or micro release binding date.

Furthermore, a minor release must contain all patches whose availability date is earlier than or the same as the release binding date.

These rules do not apply to obsolescence.

Planning Release Content

A minor release introduces non-interfering new or extensions to software functionality and architectural features, plus bug fixes.

An administrator will have the option of applying a minor release as either a true upgrade or an install. For an install, the administrator will be given tools and instructions for preserving or, where necessary and possible, converting existing "user" files.

For an upgrade, no special action will be required to preserve or convert existing "user" files (although backups are recommended). The existing system must already be installed with a release based on the same major release and must be a subset of the upgrading release. In other words:

X.Z can upgrade X.Y.A

if ReleaseDate(X.Z) >= ReleaseDate(X.Y.A) 

Violation of this rule could reintroduce a bug or de-support hardware.

New hardware can be added to a minor release only if it has FCSed on a specific realization before the minor release binding date.

Scheduling the Release

Minor releases occur with predictable regularity following the base major release. For the operating system, this probably means a minor release every 9 months. 

The set of reference realizations for a minor release level will require a full round of regression testing.

Lifetime

Shipment of the reference realizations for a minor release is discontinued when there are reference realizations for a new micro release within the minor release family. 

After a new (i.e., higher numbered) major release level is issued, minor releases in the previous major release family can be issued if the analogous bug fixes, feature content or hardware support is made available in the new major release family in a timely fashion. The new major release cannot do a true upgrade of these releases, so there is no danger of re-introducing a bug or de-supporting features or hardware by that path. However, the new major release can be installed over a minor release containing the bug fixes, features or hardware support; in the customer's view, this is analogous to an upgrade and must occur only after careful consideration.

Obsolescence

Software programs or interfaces and hardware support may be obsoleted at a minor release only after suitable warning and a phase-out or transition period. 

A major release is the preferred vehicle for obsolescence.

Micro Releases

Basics

X.Y.A [when] A > 0 [is defined to be] a micro release

Strictly speaking, micro releases start numbering from 1; however, since a major or minor release can have micro release content, some discussions will implicitly or explicitly include X.0 or X.Y.0 as a micro release.

X.Y.A [must contain] X.Y.(A-1) [when] A > 0

Any micro release must contain everything in a previous micro release against the same minor release.

Furthermore, a micro release must contain all patches whose availability date is earlier than or the same as the release binding date.

These rules do not apply to obsolescence.

Planning Release Content

Micro releases incorporate bug fixes, consolidate hardware content from specific realizations, or introduce a limited set of new peripherals. 

A micro release may introduce non-interfering new software functionality and architectural features or extensions to existing software functionality and architectural features.  A micro release does not introduce incompatibilities. Any perceptible difference between the micro release and the base minor release must be a direct and obvious result of a bug fix or the adaptation of the software to the new hardware  , or from usage of the new feature or extension .

An administrator will have the option of applying a micro release as either a true upgrade or an install. For an install, the administrator will be given tools and instructions for preserving or, where necessary and possible, converting existing "user" files.

For an upgrade, no special action will be required to preserve or convert existing "user" files (although backups are recommended). The existing system must already be installed with a release based on the same major release and must be a subset of the upgrading release. In other words:

 X.Z.B can upgrade X.Y.A

if ReleaseDate(X.Z.B) >= ReleaseDate(X.Y.A) 

Violation of this rule could reintroduce a bug or de-support hardware.

With limited exceptions, new hardware can be added to a micro release only if it has FCSed on a specific realization before the micro release binding date.

Scheduling the Release

Micro releases are scheduled as necessary to introduce new hardware or bug fixes into the manufacturing delivery channel. For the operating system, this probably means a micro release every 2 months at minimum, and less frequently if conditions permit. 

The amount of testing required is a judgment call. In general, the need for extensive regression testing of a micro release is a sign of inappropriate content and will tend to defeat the goal of short turn times for these releases.

Lifetime

Shipment of the reference realizations for a micro release is discontinued when there are reference realizations for a new micro release within the minor release family. 

After a new (i.e., higher numbered) minor (major) release level is issued, micro releases in the previous minor (major) release family can be issued if the analogous bug fixes or hardware support is made available in the new minor (major) release family in a timely fashion. The new minor (major) release cannot do a true upgrade of these micro releases, so there is no danger of re-introducing a bug or de-supporting features or hardware by that path. However, the new minor (major) release can be installed over a micro release containing the bug fixes or hardware support; in the customer's view, this is analogous to an upgrade and must occur only after careful consideration.

Obsolescence

Micro releases are not allowed to obsolete software programs or interfaces. Micro releases can obsolete hardware support after a suitable warning and a phase-out or transition period. 

Patch Releases

Basics

Patches are bug fixes that require special and immediate distribution to the field.
Distribution of patches is the responsibility of CSD.

Creation of patches is a cooperative effort of the CSD, development, release engineering and testing organizations, as required. 

Naming issues for patches are complex. A single patch realization could apply to many release realizations so a straightforward extension of the release naming scheme does not apply. Since patch names are not widely visible, issues of naming can concentrate on careful tracking of which patch realizations apply to which release realizations, and, when a patch is applied, insuring that a record is left to show that the patched system now differs from the base release realization.

This is a technical problem that needs further resolution.

Planning Release Content

Patch releases are for bug fixes. A patch may introduce non-interfering new software functionality and architectural features or extensions to existing software functionality and architectural features. In the case of new features it is preferred that they be delivered as new packages instead of as patches to existing packages whenever possible. , except to the extent that a new feature or extension introduces new behavior when used

When a patch is applied, no special action will be required to preserve or convert existing "user" files (although backups may be recommended). Dependency relationships among patches is allowed, but they may be otherwise selectively applied.

Scheduling the Release

Patch releases occur on an as-needed basis.

Patch releases should require little testing. The amount of testing required is a judgment call. In general, the need for extensive regression testing of a patch release is a sign of inappropriate content and will tend to defeat the goals of short turn times and low resource consumption.

Lifetime

Patch releases must be kept until the release realization(s) they target are no longer supported.

Patches are consolidated into all release realizations whose binding date is the same as or later than the patch availability date, and are therefore no longer needed for those releases.

Obsolescence

Patch releases are not allowed to obsolete software programs or interfaces or hardware support. 

Specific Realizations

Compatible Hardware

No software changes are needed to ship a compatible hardware product. Such products use existing realizations for Beta  and FCS. Care must be taken to regression test the products against the appropriate realizations in the field and against realizations "in the works". Future software, firmware and hardware efforts will increase the likelihood and desirability of compatible hardware.

Incompatible Hardware

A new hardware product requiring a port must target a shipping major, minor or micro release level to port and conduct full Alpha, Beta and FCS on a specific realization of the release level before it is considered for inclusion in subsequent reference realizations. 

The specific realization must be a faithful rendition of the release level, including bugs. No new software programs, features or interfaces can be introduced. Any perceptible difference between the reference realizations of the release level and the specific realization must be a direct and obvious result of adaptation of the software to the new hardware. These rules are subject to much interpretation; the ultimate determination is the domain of the Q Team for the product.

A specific realization, say for hardware A, may enter the market shortly before or after reference realizations of a higher release level and no realization of the higher release level will support hardware A at that time. In that case, a port for hardware A to create a realization of the higher release level may be called for. In any case, hardware A must be incorporated into the reference set within a reasonably short time as these "anomalies" tend to confuse customers and complicate configuration planning.

For economy, several hardware products may join to issue a composite realization.

Peripherals

Reference realizations of micro releases are permitted to introduce a limited set of peripherals. This rule is specifically intended to permit the efficient introduction of boot and console devices into the product line. The release product team can reject or remove peripherals from the reference release realizations if the number of peripherals being introduced is deemed too large or if the risk factors are felt to be too high. The release product team may require the peripheral product team to conduct a separate realization through beta test as a means of controlling risk. 

Upgrade and Patch Properties

In software terms (ignoring obsolescence), the release level (major.minor.micro) represents monotonically increasing features and fixes; this is seen as an absolutely necessary property of the release scheme. However, release levels are not strictly tied to chronological order, the set of reference realizations does not monotonically superset with release level, and certain release levels may have specific realizations in addition to the reference realizations. These factors combine to make the rules for upgrading or patching one realization with another complex: it cannot be simply a matter of higher release level, as this might undo certain hardware support or bug fixes. This must be presented to the customer, sales person and TSE in an understandable way. 

Release realization information can be supplied as matrices that give the FCS dates, hardware support, software functionality, and upgrade and patch rules for release level realizations announced, shipping or widely installed. Primitive examples of such matrices are given in Tables 1, 2 and 3, with explanatory text in the following subsection.

The exposure for "anomalies" in upgrade or patch rules creating problems for customers wanting a certain combination of hardware, software and bug fixes must be kept small and short. Every effort must be made to educate customers, sales people and TSE's to make accurate decisions in the purchase of new hardware or the use of new software. As a final measure, the information from the matrices should be encoded into the release realizations and that information used to generate a warning message if the realization upgrades or patches contrary to the rules.

Upgrade and Patch Examples

The following examples are constructed for illustrative purposes and do not reflect any known or intended release scenario. Furthermore, the examples are chosen to illustrate extreme cases and should not be construed as a reasonable way to do business. 

FCS Avaliability of Realizations

Table 1 illustrates, in matrix form, some of the points made in this section. 

A sequence of dates for reference realizations of major, minor and micro release levels is shown in the first and second columns. Note that the sequence is sorted by FCS date of the reference realizations, not by release level; hence some release levels appear to be out of sequence.

• Hardware#A issued a specific realization of 5.0 that followed 5.0 and 5.0.1 reference realizations; it does not include the bug fixes in 5.0.1. The hardware#A realization of 5.0 finished Beta before release binding of release level 5.1 and was accepted into the reference realizations for release level 5.1 and higher release levels. Logically, the 5.0.2 reference realizations could have included hardware#A, but resource constraints and priorities prevented this.
• Hardware#B issued a realization of 5.0. It was not accepted into the reference realizations at release binding for release level 5.1; thus, hardware#B also issued a realization of 5.1 shortly after the reference realizations. The 5.1 realization picked up the bug fixes in 5.0.1. Hardware#B was accepted into the reference realizations for 5.1.2 and higher release levels. Logically, the 5.0.2 reference realizations could have included hardware#B, but resource constraints and priorities prevented this.
• Hardware#C issued a realization of 5.0.1 sufficiently before release binding for 5.1, and was accepted into the reference realizations for release level 5.1 and higher release levels. It was also accepted into the reference realizations for 5.0.2.
• Hardware#D (a peripheral) was accepted into the reference realizations for micro release 5.0.2. It was not accepted into the reference realizations for 5.1 and, because of resource constraints and priorities, chose to never appear in the 5.1 family. It was accepted into the reference realizations for 5.2 and higher release levels.

For software features, release level strictly dictates supersetting of content, but chronology does not. This is demonstrated by the situation that occurs between 10/90 and 07/91 with respect to support for feature#P:

• Feature#P appears in 5.1, but not in 5.0.2 in a chronologically later release.
• Feature#P is in the specific realization 5.1/B, but bugs fixed in feature#P by the 5.1.1 release will not be fixed for hardware#B (cf. Table 3).
• Hardware#D is in the reference realizations for 5.0.2 on 11/90, but does not appear at all in the 5.1 family; therefore it does not have feature#P until release 5.2 on 07/91.

This is consistent with the software properties of release levels, and these apparent anomalies were presumably optimal for the overall business strategy given the constraints present.

Upgrade and Patch: Reference Realizations

Table 2 is organized to show whether the release named at the left of a row can upgrade (patch) the release named at the top of the column. 

Table 2 illustrates that, although a higher release level can usually upgrade (patch) a lower one, there are exceptions. In particular, release binding for 5.0.2 occurred late with respect to 5.1 and the reference realizations for that release cannot be upgraded by 5.1. Also, release binding for 5.1.3 occurred late with respect to 5.2 and realizations of 5.1.3 cannot be upgraded by 5.2.

Upgrade and Patch: Specific Realizations

Table 3 is organized to show whether the release named at the left of the row can upgrade (patch) the release named at the top of the column. 

Table 3 illustrates that specific realizations have more restrictive upgrade and patch rules because they do not appear in every family member of a release level and do not automatically receive the benefit of patch releases.

Patches may be (perhaps by design) non-interfering with changed portions of a specific release, in which case, a patch release realization from the reference realizations could be applied to a specific release realization, independent of the relative release binding dates. Careful testing must be conducted before taking advantage of these situations.

New hardware can expose bugs in portions of the reference realizations not allowed to change for a specific realization. In these cases, the preferred course of action is to leave the bug unfixed in the specific realization, deliver the fix as a patch that can apply to all relevant realizations and integrate the fix into the next release level. This mode of operation will result in the cleanest scenario for most support situations.

Client-Server Relationships

Client-Server relationships on the network are controlled carefully to preserve compatibility across the 4 types of heterogeneity that may occur singly or in any combination: 

• application architectures,
• implementation architectures,
• release levels, and
• realizations.

Special problems arise for NetDisk (an NFS-based service for diskless machines). While it is possible for NetDisk service to provide full heterogeneity features, this is done at the cost of disk space required to replicate files for commands, libraries, etc. for each possible variant of client and server. When the NetDisk client and server have the same application architecture, same implementation architecture, same release level, and same realization, disk space requirements are reduced by having the client and server share most files from the installation tape.

Problems arise when the a NetDisk client and server of the same application and implementation architecture run the same release level but different realizations: that is, either a specific versus a reference realization or two different specific realizations. For purposes of sharing, this case is treated like a machine at the same release level with the same application architecture but with differing implementation architecture; this greatly simplifies the testing, installation, support and upgrade scenarios.

Testing

The potential mix of unbundled software, services, architectures, configuration options, release levels and realizations that may appear on a customer's network makes exhaustive testing of all permutations and combinations costly in real-time, staff and equipment.

For a major or minor release, the most extensive testing feasible must be applied. However, for micro releases and specific realizations, thought must be given to reducing real-time, staffing and equipment costs of testing. For example:

• Leverage the testing from other releases;
   limiting the types of changes that are made in a micro release or specific realization is (in part) a step toward maintaining confidence in quality without extensive re-testing.
• Use the biggest possible lever;

  consider generating micro releases and specific realizations by changing the fewest possible files in the realization of the baseline minor release - if possible, copy the files directly from the minor release realization rather than regenerate them!

• Automate;

  especially for interactive components (i.e., installation), testing should be mechanized where possible.

• Subdivide;

  especially for interactive components (i.e., installation), testing of media, user interface and functionality should be separated and mechanized where possible.

• Micro-manage potential problem areas;

  certain "critical" components (e.g., compilers, installation tools, ...) should have earlier cut-offs and begin testing before other components.

• Find bad problems early;

  test components where problems are likely to require extensive retesting (e.g., compilers, installation tools, ...) as early as possible in the test plan.

Many aspects of these suggestions are best implemented as part of the process and infrastructure to support teams generating micro or specific realizations.

Release Team Relationships

Release teams operate asynchronously and must talk to each other to insure the rules set forth apply. The Q team resolves difficult questions of procedure or decides business issues. 

Feature Tapes

Sometimes it is not necessary to create a full realization to introduce a new product. In these cases, a feature tape to be applied to one or more existing releases in the field can be produced. This may prove to be a low-cost way of conducting Beta; however, a micro or minor release is still the preferred vehicle for FCS. Carrying feature tapes all the way to FCS would complicate an already overly complex set of considerations for upgrades and patches; any product team using a feature tape for FCS must clear the plans with the parent Q team and present a detailed assessment of the upgrade and patch implications for near past and near future release realizations. 

Chunks and Unbundled Products

 Encourage more chunking and unbundling as a way of making releases more manageable and as a way of giving ownership to the pieces. "Virtually unbundle" even in cases where there is a decision to bundle for purpose of pricing and delivery. The bundled SunOS product becomes the union of many products (i.e., OS, windows, languages, ....) that can be released on independent schedules of their own.

Discussion of the implications of this await further research.

Table 0: Content Rules for Release Realizations

 Key: Desirable, Not Applicable, Not Permitted, Permitted, Required, Undesirable.

For reference realizations, major release rules apply relative to any other release level; minor and micro release rules apply relative to lower release levels within their major release family.

For specific realizations, all rules apply relative to the reference release being ported, except as noted.

Footnotes:

1. if a specific realization exists for another release level, or if the specific realization is being re-issued, the analogous reference realization rule must also apply between the specific realizations.
2. micro realizations should concentrate on a single theme from:
   1. consolidation of platforms and peripherals from specific realizations.
   2. introduction of a limited set of peripherals.
   3. bug fixing.
3. hardware can only be added if it has FCSed on a specific realization.
4. differences between specific and reference realizations are characterizable within the contents of /usr/kvm.
5. Changed from NP as part of Steve C's revision.

Table 1: First Customer Ship Availability of Realizations

Table 2: Upgrade Rules for Reference Realizations

Table 3: Upgrade Rules for Specific Realizations