Include Firmware version number in data vector

[RobertK66]

Hi there, I strongly recommend to include some information about loaded firmware version(s) into the Communication structures.

This gives a good starting point for any integration tests done in the lab, when the OBC checks connectivity to all its sub devices. Giving a list of connection status and firmware version into debug output always is a good idea for documentation for any tests done...

This starts to be really useful once there is an established (maybe even automated?) procedure to make 'official releases' and make sure different binaries used in the lab have really different(increasing) version numbers. But to start with, it already helps a lot, to read something like 'V0.1dev' or so, to get a reminder that this is not yet any 'official usable' flight software 😉 ...

You can have a look at OBC, how I do this for OBC firmware. I have a compiler feature available giving me a compile time timestamp. I use this to make each developer build distinguishable (most probable). see: here in lines 27-33

When making a release I use github automation and provide the 'real version' by giving it a predefined value in 'build.h' file see: here lines 16-23 (every build after commit) and here lines 16-23 (a 'real release')

[kodsurf]

https://github.com/DominicRichter/CLIMB_PSU/issues/3

We should discus structure of datavector header in general.

[RobertK66]

@kodsurf : I think to number issues in the title is not helping a lot. If I have to refer some issue numbers I use the git internal unique number. You can see this #X after the title. With this you also can use the "#4" shortcut in git issue/comment editor where a dropdown list shows you the #XY and selecting this gives a nice reference. In your case now git # is 4 and 'yout issue number is 3 -> very confusing so.

Also using http link to an issue of format "https://github.com/DominicRichter/CLIMB_PSU/issues/4" uses the internal # number of github.

So pls. do not make things more complicated then they are ;-) and remove this title numbering here.

[kodsurf]

Maintainers of git repo are welcome to rename issue numbering as they see fit :)

Just one remark here :

When we have a multiple issues/bugs open - its good to have an indicator for

git commit -m "ISSUE-1: Firmware version added to a datavector" git commit -m "ISSUE-3: How to flash firmware guide, added to doc folder"

Then when looking into commit history :

It would clearly indicate to which issue this commit is related.

This is just an advice from my side that proper commit messaging in future will help a lot to see what has been done for which issues.

As you can see - every commit could be visualized and evaluated. That is why those git is meant for ;) It is not just a simple message that you use in order to push a commit.

In general - please do not make commits too often with small changes of typo errors. Commit should be a package

[RobertK66]

I am not arguing against using the term 'issue-x in commit comments or branch names. No I would appreciate this and promote it. BUT there is no need to have the Text "Issue-X" in the title of each issue! It is numbered automatically by github. So you only make redundant info and in case of error like here : #4 it is much more confusing.

Yes this is like git works and if you make correct reference in commit or pull request (like 'fixed #x' or so) then it also automatically sets the issue to status closed with reference to the commit. So this works for everybody smoothly without having the numbers repeated in title.

[RobertK66]

And another thing. How often one commits is personal style. I do completely not agree with your opinion that commits should be bigger 'packages'. That's the reason we have pull requests for that. I personally love and do commit as often as possible, (When it compiles and something is done. No matter how big this something was. )

[RobertK66]

An now we both are guilty by polluting discussions (in this case github procedural discussions!) into one specific issue with a very focused title. This is nonsense and it should stop here now! We should get some warnings about 'keep foccused here' from the maintainers of this repo and thats it then.....