Hey @Xerner, this is a nice idea and should work for information that we only ever need to determine for the HEAD revision of the main branch. However, my understanding is that all revisions of our README.md file (in the up-rust repo) will always refer to the same badge definition file in the gist repo, and thus they will all indicate the same (latest) version of up-spec, or am I mistaken? If so, this would mean that if I go to an older tag in the up-rust repo, the README.md would still contain a badge that would indicate the crate implementing the most recent version of up-spec, right?

Hey @Xerner, this is a nice idea and should work for information that we only ever need to determine for the HEAD revision of the main branch. However, my understanding is that all revisions of our README.md file (in the up-rust repo) will always refer to the same badge definition file in the gist repo, and thus they will all indicate the same (latest) version of up-spec, or am I mistaken? If so, this would mean that if I go to an older tag in the up-rust repo, the README.md would still contain a badge that would indicate the crate implementing the most recent version of up-spec, right?

Correct. If we wish to track historical up-spec version compatability badges when looking at past revisions, then the github action would have to commit a change directly in the README.md file to update the badge. No Gist would be used, and the badge would be a static image link. It would mean adding a commit every time the up-spec submodule changes its referenced commit. I see no issue with this

One thing that I wonder - without having looked at the details of this PR, I will do that asap - might this information (supported-spec-version) be a good datum to go into its own little text file, top-level of the repo? I'm thinking of a few use cases we could build on this, more easily than if the information was directly buried in the README:

• (put it in the README, of course)
• put it into metadata of packages when they are being published (e.g. to crates.io)
• have a dedicated little file that I can use in my TSF workflows
• have the supported-spec-version in a clearly defined and generic place, where we can e.g. then build a collection script to run through all the repos in uProtocol, and auto-generate an spec-coverage table