Update standard "development" version indicator to use 0xFF

[astrogeco]

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I reviewed the cFS README.md file to see if the feature is in the major future work.
• I performed a cursory search to see if the feature request is relevant, not redundant, nor in conflict with other tickets.

Is your feature request related to a problem? Please describe.

Historically, setting the Revision number to "99" indicates that the source code in question is a "development" version and thus hasn't been fully tested.

In nasa/osal#824, we put this information in the Mission_Rev instead and set it to "0xFF". This pattern has a couple of problems:

• It is not standard, cFE documentation needs to be updated
• If a user changes the MISSION_REV while building on top of a development version, there is no way to know what the original version was by looking at source code. (eg x.y.z.99 is changed by a user to x.y.z.100) kudos to @skliper for this observation
• Older telemetry or "ground" systems may be used to the two-character legacy number of "99" instead of "0xFF" and convert the value into a two-character string thereby cutting off the value.

Describe the solution you'd like

1. Revert to using the Revision number
2. Move from 99 to 0xff
3. Communicate the change to users

Describe alternatives you've considered
Keep Revision = 99

Additional context

Need to open related Issues in other cFS component repositories

Requester Info
Gerardo Cruz-Ortiz, NASA

[jphickey]

This was discussed in today's CCB, and also in discussion on nasa/cFE@e5be061

My concern is that all three numeric version numbers (major, minor, revision) are important for identification of what the real software baseline is, and important to keep this accurate within HK TLM, even for development versions.

Even if that baseline information may exist in the form of a string, this is not ideal because that string doesn't follow a strict format, nor is it easily possible to compare a string and determine simple things like "is this version newer than that one"? Strings are OK for humans to read, but not so good for scripts. For example, a feature/command may have been added in one version of the software, and a test script may need to know what version is running to decide whether or not to send a particular command. So it is beneficial to make the version number meaningful for scripts and tools, not just humans, and strings don't work well in that regard.

Problem Context

Originally when versioning was discussed during the Bootes versioning cycle, the following was accepted as truth:

1. end-users should only deploy "official release" versions to their flight products as a baseline
2. software needed to self-report whether it was in fact an "official release" (deployable to flight products) or a "development" version (modified from that official release, including versions pulled from main branch on github at any given time). In the latter case, it should self-report the official version it is based on.
3. end-users (and only end-users) should bump the "mission rev" value whenever they modify the software from its original form, to track the fact that it no longer matches the official release.

Because of rule (1) and (2) above it meant that use of MISSION_REV and the "development version" status became exclusive of each other. That is, development versions would never change MISSION_REV, and conversely, those who might need to update MISSION_REV do not use development versions. So it was a good fit to reserve the value 0xFF as a flag to indicate this status, since (it seemed like) this would never interfere with the original intent of this value.

However, as discussed at 2022-03-23 CCB, this is no longer the case, really. Due to the release process timeline far exceeding most real project schedules and deadlines, it is not practical for end-users to wait for official release status. As a result, use of MISSION_REV is now not as clean-cut - even tagged versions still need to report themselves as "development" - and users may need to use the MISSION_REV to track the fact that they've made a change, even when this field is already set to 0xFF.

In most open source projects, versions numbers are bumped up at the discretion of the development team, once milestones were met. However, due procedures and policies unique to CFS, historically the development team has not been able to update the version number, because a version number update implied "official release" which in turn implied that the full release cycle was done, but this takes years.

Possible Solution

If the policies and procedures permit, the "official release" implication/designation could be associated with something other than the numeric version. This would free the dev team up to bump the self-reported version numbers whenever meaningful functionality has been achieved and acceptance testing has passed, much like every other project manages version numbers.

The advantage is:

• With much more frequent releases, end-users would be less compelled to use a mainline version for actual deployment (they actually can wait for a real version bump)
• The major/minor/revision numbers being reported in TLM actually become meaningful again (since every version of CFE would not need to report itself as "6.7.0" anymore)
• Could also adopt a versioning scheme where odd-numbered revisions indicate mainline development, and even-numbered revisions indicate stable points (i.e. where the full suite of acceptance testing was done, and all documentation was updated, etc).

In short, decoupling the notion of "what went through the complete/official SRA legal review process" and "what software is stable and high-quality such that end-users can deploy it and expect it to work" would do a lot of good, both for internal and external users.