Alerts Regarding API Breaking Changes

[arizvi786]

The following commit introduced an API breaking change to the comm component instance in reference deployment: e9ea56d#diff-564a5d759ba8dfa8a6f4549667dc381692ff57a046ecd445b375b08e3876f606.

More specifically, the start() interface was updated from: comm.start(name, true, COMM_PRIORITY, Default::STACK_SIZE); to comm.start(name, COMM_PRIORITY, Default::STACK_SIZE);.

This may not have resulted in any issues on the F' side since the API change is reflected in the use-case in RefTopology.cpp file. However, someone pulling in the latest F' changes in devel branch may not have expected this API to change. Also, this API change didn't result in any compilation error and went unnoticed until the custom application deployment (i.e. not Ref deployment) started crashing upon receive of a command from GDS that uses the same comm instance. This was a puzzling error and it would have been nice if this was somehow highlighted to alert exiting users already using the comm component instance in their topologies.

I would recommend a concise alert message be available to users regarding any API breaking changes being merged to devel branch. I'm not sure if/how this would have been captured in the release notes.

[LeStarch]

@arizvi786 for a given release we document changes that will break users. v3.6.0 is the first to contain this specific change and the release notes do capture that change: /~https://github.com/nasa/fprime/releases/tag/v3.6.0

As you know devel will occasionally merge breaking changes as this is the nature of development. When such a PR is requested we tag it with the label "Updated Instructions Needed". This is a flag to our team to capture this breakage in the release notes. We have one such change proposed at this time: /~https://github.com/nasa/fprime/pulls?q=is%3Apr+is%3Aopen+label%3A%22Update+Instructions+Needed%22.

A project could watch for PRs with those labels being merged to know when devel will require updates. Is that a sufficient enough alert system? If not, what channel would you propose for such alerts?

[arizvi786]

@LeStarch thanks for the feedback. This seems sufficient. Also, it further reinforces my approach to only use tagged/released versions of F' rather than a commit to a branch unless it's for temporary use.

[arizvi786]

@LeStarch one recommendation for your consideration on this as follows: If there's an API breaking change that's NOT backwards compatible, such as the example referenced above, then the change must be implemented in a way that it leads to compilation error if the API usage is not updated by the user. This would guarantee alerting the user if the API is being used.