Jake Hageman

Also worth keeping in mind in flight there are com blackouts, watchdogs, reboots, multiple images, etc. I often see "red limits" put on version numbers in telemetry to immediately identify...

@jphickey - yup, I'm agreeing with everything you are saying. What I don't understand (still) is what problem we are trying to solve relative to our current implementation (+ your...

> ...really superfluous... @jphickey Agreed. I like the enhanced version reporting, everything is uniquely identifiable and can be reported in event messages. I also think there's good reasoning behind the...

Beyond that, I struggle to understand what additional build numbers, strings, etc gives us. For reference, when I say enhanced versioning I'm referring to git describe, build username, and build...

Maybe HK could report MAJOR.MINOR.REVISION.MISSION_REV on releases and MAJOR(of last baseline).MINOR(of last baseline).99.BUILDNUMBER? Then the build number is traceable between the two?

where for 99.BUILDNUMBER we are reporting build number from version.h... (which could be filled in w/ a git hook?) EDIT: where build number comes from git describe... so would match...

If we always use the MAJOR.MINOR.0 release as the baseline for counting our build number then we can stay with MAJOR.MINOR.99.BUILDNUMBER? Basically you could tell what the real baseline was...

Is it worth changing version reporting in TLM for development versions 3 times in 3 releases vs just 6.7 cycle being unique (since I broke the pattern) just to get...

I'm fine with your suggested change (0xFF in MISSION_REV). Seems like a fair balance of info vs bandwidth. It's a change to the hk packet either way since neither PSP...

> Yes, we'd need to add PSP info to the ES HK TLM. The mission rev is already in there though, for OSAL and CFE at least. The only change...