Missing migration path for CFE 6.5 ES enum values

[skliper]

In CFE 6.5, ES introduced scoped names for several enumerated constants and deprecated their old names.
For example, CFE_ES_RUNSTATUS_APP_RUN was introduced to replace CFE_ES_APP_RUN. While developers were encouraged to migrate to the new names and an example sed command was given, the old names remained usable unless CFE_ES_ENABLE_NEW_ENUM_NAMES was defined.

CFE 6.6 introduced a different style of scoped names, e.g. CFE_ES_RunStatus_APP_RUN, and provided aliases to the pre-6.5 names, but did not provide compatibility aliases for the 6.5 versions.

The result is that developers who attempted to follow the new naming scheme in 6.5 found their apps failing to build in 6.6, whereas using the deprecated name would have continued to work.

CFE 6.6 should provide aliases for the names from 6.5 as well as the pre-6.5 names.

For example, in addition to
{{{#!C
#define CFE_ES_APP_RUN CFE_ES_RunStatus_APP_RUN
}}}
there should be
{{{#!C
#define CFE_ES_RUNSTATUS_APP_RUN CFE_ES_RunStatus_APP_RUN
}}}

[skliper]

Imported from trac issue 287. Created by tflemin1 on 2019-05-01T13:27:25, last modified: 2019-07-17T16:56:49

[skliper]

Trac comment by jphickey on 2019-07-01 15:17:39:

The change made in CFE 6.5 was just to address a couple problem areas, whereas the change in 6.6 was across-the-board to adhere to an actual documented convention. The convention is attached to ticket #207, although it looks like this was never put into the "docs" directory. It might fit better as a chapter/section in the existing documents anyway.

At any rate, there was some unfortunate thrashing as a result.

I vaguely recall a CCB discussion about this, and it was assumed that if a developer was aggressive enough to apply the sed command for CFE 6.5, the same could be done for CFE 6.6, and this would only be a very small subset of users.

That being said, I'm not sure if its practical at this point to include mappings for the names that only briefly existed in 6.5, since 6.6 is already out. The problem with the mappings is that eventually we need to remove these crutches.

Hopefully the current 6.6 convention can "stick" permanently....

[skliper]

Trac comment by jhageman on 2019-07-01 16:04:38:

Marking for CCB review - more for philosophy discussion. Encouraging app developers to perform the trivial update is preferable to incurring more technical debt in the cFS Framework to support backwards compatibility. Feel free to add a compatibility header to a techdev branch if a fix is useful to share (or attach here, or clone and post to github, or whatever), but I'd prefer to avoid adding these mappings to the development branch.

A major goal for 7.0 will be to clean out old compatibility complexity and focus on simplifying future support.

[skliper]

Trac comment by jhageman on 2019-07-03 12:48:08:

Moved unfinished 6.6.1 issues to next minor release

[skliper]

Trac comment by jhageman on 2019-07-17 12:28:31:

CCB - 7/17/2019 discussed and agreed to close as wontfix and attempt to avoid this situation in the future (recommend fixes that break future compatibility)