MPI Version Numbering

Software Life Cycle Policy | MPI Release Types | MPI Version Numbering |
General Example | Branch Example

Major

The Major number indicates a fundamental change in the system architecture, severe technical changes, or major new functionality. Any type of change is possible for a major version release.

Interface changes may include:
  • Add new methods, structures, enumerations, or defines
  • Remove or change methods, structures, enumerations, or defines
  • Remove deprecated methods, structures, enumerations, or defines

Application Compatibility
An application written for a previous minor release must be recompiled. Additionally, there might be source code level changes for methods, structures, enumerations, or defines. All deprecated code will be removed at the major version change.

Minor

The Minor number signifies the addition of new modules, new features, expansion of existing features, or minor changes to the interface. The changes are limited for a minor version release. A minor release will support features that existed in a previous minor release.

Interface changes may include:
  • Add new methods, structures, enumerations, or defines
  • Deprecate existing methods, structures, enumerations, or defines
  • Minor changes to existing structures, enumerations, or defines

Application Compatibility
An application written for a previous minor release must be recompiled. The new minor release will still have all of its previous methods, structures, enumerations, and defines. It may also have new methods, structures, enumerations, or defines. It may have minor changes to existing structures, enums, or defines. Once an application begins to use the new methods, structures, enumerations, or defines, it may become incompatible with previous minor releases. However, an application can become compatible with a new minor release with a few minor changes.

Interface changes are kept to a minimum. They are only implemented when absolutely necessary to expand an existing feature or correct a problem. Interface changes will enable application compatibility issues to be discovered at compile time instead of at run time.

A new minor release may deprecate methods, structures, enumerations, or defines. An application will be required to include a "deprecated" header file to access the deprecated code.

Release

The Release level indicates the relative maturity of the release. It follows an ordered progression:

  • DevX – Development Release Type, number X
  • AlphaX – Alpha Release Type, number X
  • BetaX – Beta Release Type, number X
  • XX – Production or Patch Release Type, number XX

Application Compatibility
Dev, Alpha, and Beta releases follow the same change limitations and application compatibility rules as minor versions, unless the major version number changes, in which case it will follow the compatibility rules of major versions.

Patch releases are interface and binary compatible with a Production or a previous patch release. Interface changes for methods, structures, or defines are not allowed. New members may be added to enumerations, as long as they don’t change the value of existing members. New macros, constants and functions can be introduced.

If an application uses an API which has become available in a particular release, it will no longer build or operate with previous versions.

New elements added to an existing enum type can cause backward compatibility issues. The problem occurs when a program contains a static list that has a one-to-one relationship to the elements in an enum. If new elements are added to the enum, then elements must also be added to the list. It is recommended that the length of such lists be verified at run-time.

Below is an example of a static list that is mapped to the elements of the MPIControlIoBit enum type. The example also shows how to verify that the length of the list is correct.

static unsigned bitMasks[/* MPIControlIoBitLAST */] = {
/* MPIControlIoBitUSER_0_IN */	1 << MPIControlIoBitUSER_0_IN;
/* MPIControlIoBitUSER_1_IN */	1 << MPIControlIoBitUSER_1_IN;
...
/* MPIControlIoBitUSER_5_OUT */	1 << MPIControlIoBitUSER_5_OUT;
};

#define _countof(array) (sizeof(array)/sizeof(array[0]))

ASSERT(_countof(bitMasks) == MPIControlIoBitLAST);

Branch.Release (optional)

The Branch number identifies a branch from an existing version (Major.Minor.Release) or from another Branch. The Branch number is incremented for each instance of a Branch from an existing version (or from an existing Branch). The Release level definition is the same as defined in Major.Minor.Release.

The Branch.Release identifiers are always added as a pair. Every Branch REQUIRES a corresponding Release. Using Branch.Release makes it possible to trace back to any previous Branch.Release and eventually back to the starting Version. It provides a traceable history for infinitely expandable, multi-branched, multi-release trees.

Application Compatibility
Branch.Release releases follow the same change limitations as minor versions. Since a Branch development is customer specific, the scope of its changes can vary. Please consult the Release Notes section or MEI for details.

Using this scheme, every software build/release is guaranteed to have a unique identifying value.