Clarification of the `[Updated: XX/YYYY]` tags

[mooreryan]

Hi, thank you for this awesome resource!!

I was wondering if you could clarify the usage of [Updated: XX/YYYY] tags that are associated with some of the tools.

The contributing guide didn't mention them and I checked a couple of repositories and the last update of the software itself doesn't match the Updated tag on the readme.

For example, VirHostMatcher has [Updated: 01/2025] [Updated: 01/2025] (multiple tags), but the last commit to the GitHub repository was seven years ago.

Or another example: vRhyme has [Updated: 02/2025] [Updated: 02/2025], but the last commit was three years ago rather than last month.

So, I think I must be misunderstanding the point up the updated tags, as they appear to not be connected to the last update of the tool. Are they references to when they were added to the list before the list was made available on GitHub?

[shandley]

Hi @mooreryan. These automated metadata assignments are still a bit of a work in progress. They are run through GitHub actions now and are still a bit buggy, but I have an active branch where I think I have solved most of the issues.

To summarize what these tags mean as you saw them:

• [Updated: MM/YYYY] indicates when the repository link was last verified as working by the GitHub Action
• It does NOT indicate when the source repository was last updated with code changes

1. The original code was using a regex to search for existing [Updated: XX/YYYY] tags, but it wasn't handling
   duplicates correctly
2. When it found a match, it would use a simple text replacement which could result in duplicated tags if the
   pattern appeared multiple times

I fixed the duplicate due to the regex in the branch and am working on a way to show when the repo was actually last updated instead of when the repository link was last verified by my GitHub action as that is much less useful.

Scott

[mooreryan]

Thanks for your explanation that makes sense.

am working on a way to show when the repo was actually last updated instead of when the repository link was last verified by my GitHub action as that is much less useful.

I had a bit of a look through your main branch and saw that it may be as straightforward as updating the enhanced_repo_metadata.py since that appears to be already managing the GitHub API with a nice wrapper. I haven't put much thought into how that would look, or which other downstream scripts may be involved however.

I did go and check through your other branches to see if you might be actively working on it, there were a lot of branches with very recent updates, and so I wasn't too sure of the process going on there.