One one hand, this bug is sort of hard to handle. The Guidelines evolves without fixed release dates, and even if f-r is actually released after a change there's no way to know whether a guidelines change is reflected in f-r.

On the other hand, this is an important issue. I think the basic problem is that f-r might be misunderstood to handle more that it actually does. One thing it definitely not does is to cover the complete set of Guidelines.

Most (all?) manual review templates used have an overall 'Package meets the Packaging Guidelines' item. One way to handle this bug could be to introduce such an item, which definitely should push the responsibility for this to the reviewer; after all, that's where it belongs. f-r can do some boring things, but the evaluation should be done by the reviewer.

That will teach me to write bugreports for myself without enough information for others :-)

The idea was that each subclass (Java, Ruby, Python etc) checks could contain an information which could be checked automatically. Original idea was to check html modified headers, but those change without content change on the page unfortunately. So let's say we automatically parse https://fedoraproject.org/w/index.php?title=Packaging:Java&action=history and decide that date of latest change is 20th July 2011, 17:00. We can ask developers (not that many of us) to add this information to base class of their reviews and update it when they add information. If there was a change in the guidelines, we can display warning. If not...nothing will change in the output.

A simple step in the right direction would be to display the 'last changed' date at the bottom, as part of the version info.