Okay, so where I work we manually create "versions" of Word docs and spreadsheets as we collaborate on them with our colleagues. Here's an example workflow.
File.doc //First version, created by me. I send it to my boss. It comes back with replies and questions.
File 2.doc //Return from my boss with her replies and questions.
File 3.doc //My reply to my boss.
File 4.doc //My reply to my boss.
If a file name ends in a number (such as a date) we use letters instead of numbers, as in:
File 9 January 2019.doc //First version, created by me. I send it to my boss. It comes back with replies and questions.
File 9 January 2019 B.doc //Return from my boss with her replies and questions.
File 9 January 2019 C.doc //My reply to my boss.
File 9 January 2019 D.doc //My reply to my boss.
Using Opus, I would like to colorize (in a lister) all but the latest version of a doc/docx or xls/xlsx file. I'd like the file names of the older "versions" of a versioned file be a certain shade of gray. This way I'm less likely to accidentally edit an old version (something we almost never want to do) and I can also more easily find the latest version.
One directory could contain multiple different groups of unrelated versioned files.
When there's just one file (no version of that file with a " 2" or higher or " b" or higher name), then that non-versioned file is the latest version and would its name would be normal (black characters).
It is possible, but would take some script code to do, and is a little fiddly to do. I've been meaning to have a go at implementing it but haven't had a chance yet, since it's not trivial. (The issue is that the property of each file depends on other files, so the script would have to look at the whole directory for every file.)
It's certainly possible, though.
As an aside:
If you do this sort of thing a lot, it might be worth looking into a version control system which can let you store multiple versions of each file and keep track of their history, with dates and comments and the ability to compare versions. (Although comparing .doc files doesn't always work perfectly, depending on the comparison tool used.) We use SVN and Git which are geared towards programming, and can be integrated into Opus or used standalone. There may be others more aimed at documents.
About using SVN, Git or some other VCS: That won't work. My (small) company uses this method of versioning-by-filename broadly. Lots of admin people do it. Thanks for the suggested alternative. We do use SVN and Mercurial for things that make sense for us.
There are not supposed to be any such gaps. And I cannot remember ever seeing one, so we can consider them very rare. However, if there were a gap, the version of that file with the highest version value would still be the optimum winner to be treated as "latest".
After file 9, we go to file 10. After file Z we go to file AA, then file AB.
Note that these versions have a relatively short life cycle. We use them to collaborate on files for days or weeks and when we're done we toss out the old versions of that file and remove the version suffix from the final version of the file. That's our workflow. We don't use this for long-term file versioning as that would be a terrible practice.
I have a solution for that which works for us but I realize it is not going to solve it for other people.
We always (required by company disambiguation policy):
Always put the day number before the month name.
Always spell out the month name. (Not relevant, I know.)
Always include years when we mention dates in file names.
Always use four-digit years.
And we never go past two-character revision numbers. So if trailing number in file name is four digits long we know it's a year, not a revision.
Again, I realize this only works for us — not for the world at large.
Maybe a nice rule to make this more generally useful would be: Only works if there is an unbroken chain of revision file names (starting at B or 2 and continuing until there's a gap) and just live with the fact that a gap (missing revision file name) breaks the colorization for file names after the gap. A file with a name like "file 2019.doc" wouldn't be colorized because there'd be no "file 2.doc" through "file 2018.doc" files in that directory.