Summary

The general story behind this is outlined in #2153 - ultimately, this has Capistrano start to manage a REVISION_TIME file which holds a unix timestamp of when the release was committed, in the same way that it stores that releases SHA in REVISION.

Resolves #2153

Short checklist

• Did you run bundle exec rubocop -a to fix linter issues?
• If relevant, did you create a test?
• Did you confirm that the RSpec tests pass?

Other Information

I think this is actually pretty close to being landable since I figured out the general "how" a while ago in another project, but I expect some tweaking will probably be required and it would be nice to support this for svn and hg if possible but I don't use those tools so will either need someone who does to provide insight or I'll see if I can google/chatgpt a solution.

Some general questions I have are:

• do we want to have a dedicated set of tasks, or fold this into the current "revision" based ones?
• in the context of custom SCMs, do we want to make this an optional extra or required?
• if optional, do we need to have any custom/extra checks? (I noticed that there are some NotImplementedError methods but it didn't seem like they were actually being called by Capistrano itself)
• if the revision time isn't available, do we want to create an REVISION_TIME file at all? (it'd be simpler, but an empty file)