High level version verification

[TrevorDecker]

High level version verification and checking low level version
The low level system can be asked to send informative messages, code version number, who compiled it, the date of compilation.
We want for the high level software to display a warning if the low level version is not what high level expects
We want to be able to easily see who compiled the low level software and when it was compiled

[jesseanderson]

High level will determine its commit hash at compile time. Low-level RBSM message will be compared against this compile-time hash. If different, warning will be displayed to the UI.

[jesseanderson]

@TrevorDecker @ramensandwich Alright, I'm trying to figure out what features need to be implemented to make true "version verification" using the low-level fingerprint. I see a few options, but I'm not sure what will be useful or what was talked about previously. One option I see is displaying a warning if the most recent low-level commit hash is not the same as the high-level commit hash. It would appear to me that this has limited use, because there are many situations in which either low-level or high-level is ahead, but there is no compatibility issue.

I think I could also search backwards through the git tree to see if the commit hash being sent by low-level is a parent of the current high-level commit. Also not sure what this would say about version compatibility.

Another option is some curated compatibility list, which I see as non-ideal because someone has to curate it which seems like a pain.

Can one of you guys remind me what the intent was here? I know I said I'd do this a long time ago, but I have some time this week, I'm just no longer sure what the intent was. Thanks!

EDIT: I see above that at some point we had the idea to have a curated compatibility list. Are we sure that still makes sense? I have trouble believing committers that change compatibility details are going to want to or remember to update some document of compatible commits. Also, if we did this, would semantic versioning not be easier to maintain?

EDIT 2: I want to clarify that I'm not trying to rock the boat here, I just want to build this (long overdue) feature in a way that leverages already completed work to be useful for operation of the buggy. Thanks again guys.

[TrevorDecker]

I think we will get our biggest bang for the buck by providing a warning if the commit hash's don't match. The main purpose of the fingerprint system is to verify that the code we are running on low level is what we expect.It would also be useful to just display and log the hash/branch name of what is on low level.

The question of what is running on low level comes up surprising often. Additionally when unexpected behavior shows up we have no easy way of knowing what branch low level was on. Making the problem difficult to reproduce and classify as a major problem or expected.

We could try using the git branch tree and say that compatibility is linked to changes in the low level directory. Ie if commit x is only a change of high level then we should not report a compatibility issue. But I think this would be large amount of work for minimum pay off.

As for design changes, I am all for making architecture changes just so long as they are helpful and we have time to test them before race day (9 weeks from now)