|
22 | 22 | bug fixes or major documentation updates. |
23 | 23 | The Revision number may also be updated if there are other changes contained within a release that make |
24 | 24 | it desirable for applications to distinguish one release from another. |
25 | | - WARNING: The revision number is set to the number 0xFF in development builds. To distinguish between development |
| 25 | + WARNING: The revision number is set to the number 99 in development builds. To distinguish between development |
26 | 26 | builds refer to the BUILD_NUMBER and BUILD_BASELINE detailed in the section "Identifying Development Builds". |
27 | 27 |
|
28 | | - The Mission Version number is set to zero in all official releases, and is reserved for the mission use. |
| 28 | + The Mission Rev Version number is set to zero in all official releases, and is reserved for the mission use. |
29 | 29 |
|
30 | 30 | <H2> How and Where Defined </H2> |
31 | 31 |
|
32 | 32 | The version numbers are provided as simple macros defined in the cfe_version.h header file as part of the |
33 | 33 | API definition; these macros must expand to simple integer values, so that they can be used in simple if |
34 | 34 | directives by the macro preprocessor. |
35 | 35 |
|
36 | | - Note the Mission Version number is provided for missions to be able to identify unique changes they |
37 | | - have made to the released software (via clone and own). |
| 36 | + Note the Mission Rev number is provided for missions to be able to identify unique changes they have made to the released software (via clone and own). Specicifally, the values 1-254 are reserved for mission use to denote patches/customizations while 0 and 0xFF are reserved for cFS open-source development use (pending resolution of nasa/cFS#440). |
38 | 37 |
|
39 | 38 | <H2> Identifying Development Builds </H2> |
40 | 39 |
|
41 | 40 | In order to distinguish between development versions, we also provide a BUILD_NUMBER. |
42 | 41 |
|
43 | 42 | The BUILD_NUMBER reflects the number of commits since the BUILD_BASELINE, a baseline git tag, for each particular |
44 | 43 | component. The BUILD_NUMBER integer monotonically increases for a given baseline. The BUILD_BASELINE |
45 | | - identifies the current development cycle and is a git tag with format vX.Y.Z. The Codename used in the version |
| 44 | + identifies the current development cycle and is a git tag with format vMAJOR.MINOR.REVISION. The Codename used in the version |
46 | 45 | string also refers to the current development cycle. When a new baseline tag and codename are created, the |
47 | 46 | BUILD_NUMBER resets to zero and begins increasing from a new baseline. |
48 | 47 |
|
|
53 | 52 | name; for example, osal uses OS_, psp uses CFE_PSP_IMPL, and so on. |
54 | 53 |
|
55 | 54 | Suggested pattern for development: |
56 | | - - XXX_SRC_VERSION: REFERENCE_GIT_TAG"+dev"BUILD_NUMBER |
| 55 | + - CFSCOMPONENT_SRC_VERSION: REFERENCE_GIT_TAG"+dev"BUILD_NUMBER |
57 | 56 | - Example: "v6.8.0-rc1+dev123" |
58 | | - - XXX_VERSION_STRING: "XXX DEVELOPMENT BUILD "XXX_SRC_VERSION" (Codename: YYY), Last Official Release: ZZZ" |
| 57 | + - CFSCOMPONENT_VERSION_STRING: "CFSCOMPONENT DEVELOPMENT BUILD "CFSCOMPONENT_SRC_VERSION" (Codename: CFSCONSTELLATION), Last Official Release: MAJOR.MINOR.REVISION" |
59 | 58 | - Example: "cFE DEVELOPMENT BUILD v6.8.0-rc1+dev123 (Codename: Bootes), Last Official Release: cfe v6.7.0" |
60 | 59 |
|
61 | 60 | Suggested pattern for official releases: |
62 | | - - XXX_SRC_VERSION: OFFICIAL_GIT_TAG |
| 61 | + - CFSCOMPONENT_SRC_VERSION: OFFICIAL_GIT_TAG |
63 | 62 | - Example: "v7.0.0" |
64 | | - - XXX_VERSION_STRING: "XXX OFFICIAL RELEASE "XXX_SRC_VERSION" (Codename: YYY)" |
| 63 | + - COMPONENT_VERSION_STRING: "CFSCOMPONENT OFFICIAL RELEASE "CFSCOMPONENT_SRC_VERSION" (Codename: CFSCONSTELLATION)" |
65 | 64 | - Example: "cFE OFFICIAL RELEASE v7.0.0 (Codename: Caelum)" |
66 | 65 |
|
67 | 66 | **/ |
0 commit comments