With the release of GSD 3.4.0, the use of a four-segment version number has been adopted. The three-segment version numbers used from GSD 3.0.0 through GSD 3.3.0 Beta and the new four-segment numbers are identical except for the addition of the fourth component, the release number. This number is used in a multi-phase release, typically to uniquely identify the final release of a software delivery and the various beta releases preceding it (for example, GSD 3.4.0.1 Beta, GSD 3.4.0.2 Beta, and GSD 3.4.0.3, identifying the first beta release, second beta release, and final release for the GSD 3.4.0 baseline, respectively).
<Major Version Number> . <Minor Version Number> . <Patch Version Number> . <Release Version Number>
This is in contrast to the previous version number scheme used by GSD. For a description of this scheme and how it relates to the current scheme, see below.
The major version number is used to indicate significant changes between GSD versions. Historically, these changes have occurred when moving from one version of a MIL-STD to another, such as from MIL-STD-2525A to MIL-STD-2525B. Major version releases are characterized by changes to APIs, data structures, MIL-STD icon ID changes, GraphRep-Overlay changes, etc. These changes have a major impact on interoperability and the level of effort required for integration.
BackThe minor version number is used to indicate less significant changes for the majority of our users. Historically, these changes have included GraphRep-Overlay modifications, new versions of MIL-PRF-89045, and the addition of new GSD features (Free Hand symbology, attribute context modifications, etc.). These changes have a lesser impact on interoperability and the integration effort than the types of changes included in a major release.
BackThe patch version number is used to indicate releases that include fixes for problem reports. Historically, patch releases have included API and data structure changes. However, going forward it is our policy that, generally, patch releases will not impact interoperability or require anything more than a recompile/relink. However, there may arise instances where a required fix will necessitate code changes when performing the integration. These instances will be kept to a minimum.
BackThe release version number is used to uniquely identify the various phases of a release. Typically, the release number will be used to identify the various beta releases and the final release comprising the delivery of a new software baseline. Successive releases, denoted by a higher release version number, will include functionality, bug fixes, and documentation not available for release in previous deliveries.
BackGSD used to use a two segment version number with a conditional patch version indicator:
<Major Version Number> . <Minor Version Number> [P<Patch Version Number>]
For a description of the new version number, see above.
The major version number was used to indicate significant changes between GSD versions. Historically, these changes occurred when moving from one version of a MIL-STD to another, such as from MIL-STD-2525 to MIL-STD-2525A. Major version releases were characterized by changes to APIs, data structures, MIL-STD icon ID changes, GraphRep-Overlay changes, etc. These changes had a major impact on interoperability and the level of effort required for integration.
BackThe minor version number was used to indicate less significant changes for the majority of our users. Historically, these changes had included GraphRep-Overlay modifications and the addition of new GSD features (Free Hand symbology, attribute context modifications, etc.). These changes had a lesser impact on interoperability and the integration effort than the types of changes included in a major release.
BackThe patch version number was used to indicate releases that included fixes for problem reports. The version number did not include a patch indicator until a patch had been released (that is, there was no such thing as GSD 2.2 P0 to indicate the initial release; rather GSD 2.2 was used). Historically, patch releases had included API and data structure changes. These changes may or may not have impacted interoperability and usually were not simple "plug-in" upgrades.
BackMapping between the old and new version schemes is a straightforward process. To convert from the old scheme to the new, keep the major and minor version numbers from the old scheme version number, and append the patch version number to the end (in the cases where there is no patch version number, append 0). For example GSD 2.2 converts to GSD 2.2.0; similarly, GSD 2.1P5 (GSD 2.1 Patch 5) converts to GSD 2.1.5.
-
-
