How to best indicate an example is up-to-date?

[maximlt]

Each example is displayed as if it were a sort of blog post, with a title, author, labels, and creation date. In a previous iteration, we also introduced Last updated (either set manually in the project file or computed automatically based on the last time some files were modified in the project). In #461 I changed Last updated to Modified, as I felt the former implied too much. Fixing a typo or an old link isn't the same in a notebook as modernizing an example like we did this year, thanks to the NF SDG grant.

What we want to convey imo is how up-to-date an example is. I suggest that this is best translated by the versions of the packages it depends on. An example relying on Python 3.6, or Panel<1, cannot be up-to-date. Or, put in other words, if someone puts some work into modernizing an example, it's likely they will update its lock file to pull the latest versions. We have all the information we need (direct dependencies in the project file, installed versions in the lock file) to generate a view of the packages and their versions that can be displayed on each example page (displayed exactly how is TBD). Displaying this would be useful in its own right, I assume some people might want to copy/paste code snippets from an example that will fail in their environment due to version mismatches, which they could then more easily debug.

An alternative would also be to simply disable computing last_updated automatically (git diff) but only rely on the value entered in the project file, if any.

[jbednar]

Certainly some interesting possibilities there!