Add a cooldown option to `hex.outdated`

[elfenlaid]

What

It would be nice to have a flag that filters out outdated packages based on their date of publication.

For example, mix hex.outdated --cooldown=7-days will mark outdated packages that were published less than 7 days ago as Update not possible despite their versions.

Why

The motivation behind it is that some supply chain attacks could be mitigated or softened by introduction of dependency cooldowns: https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns

Another thing is that even minor tweaks create unexpected consequences. For example Default response_encodings change in 1.10.0 breaks HTTP client compatibility · Issue #557 · mtrudel/bandit was introduced partly by changing compression priority (there was a larger bug with compression going on underneath, but it was hard to notice due to the compression algorithm in question being rarely if ever called).

All in all, taking a more conservative stance on dependency updates could be beneficial. On the other hand, I'm not sure whether this approach is something that the Hex team wants to "promote" by adding cooldown flags.

Next

It would be nice to hear thoughts from the Hex team regarding this issue. Whether this approach makes sense in general and whether it is applicable to the hex.outdated command.

If it does sound like something worth adding to hex.outdated, I am more than willing to help.

[grzuy]

Not an hex maintainer here, but sharing my thoughts.

Interesting proposal.

Maybe a different way to approach the same issue could be displaying the published date of the "Latest" version of each listed package? Either in a date format or a "X days/months ago" type of format? O both.

Might help you decide which updates to prioritize and which to wait for, without having a new command option that filters the outdated package completely?

[elfenlaid]

Maybe a different way to approach the same issue could be displaying the published date of the "Latest" version of each outdated package? Either in a date format or a "X days/months ago" type of format?

Yeah, that could also work and would be easy enough to pipe through awk-like utilities.

[ericmj]

We can add the publish date to the table we print in mix hex.outdated.

Not a fan of the cooldown option though, at least as it is currently proposed. Some things to consider:

• "Update not possible" is not really true, the update is possible but you may not want to update. Consider printing something like "Recently published" in yellow as a warning instead.
• What happens to packages that are published every 7 days or more often, will it always show "Update not possible" or should we consider matching against other versions than the most recent on? This may be confusing when you run mix deps.update though because that would given you the most recent version and having a mismatch between deps.update and hex.outdated seems even more dangerous.
• What you really want to protect against is what mix deps.update does, mix hex.outdated is just a visualization tool, it doesn't actually protect you from harmful package updates.

[elfenlaid]

That's reasonable critique. Let's focus on adding the publish date.

Currently hex.outdated supports the following flags:

Supported options:
  --all, --no-all
  --only STRING
  --pre, --no-pre
  --sort STRING
  --within-requirements, --no-within-requirements

I'm not sure if the publish date column should be behind some sort of a flag, like --include-publish-date or something. That could in theory prevent breaking of scripts that depend on text shape output.

Also, probably--sort STRING could accept something like publish-date, but again, I'm not sure if this kind of sorting would be useful on its own.

[ericmj]

We should always include the date in the table, we don't have a stable API for mix tasks. I don't think sorting by publish date is very useful, I can't think of when I would want to do that.

[elfenlaid]

We should always include the date in the table, we don't have a stable API for mix tasks. I don't think sorting by publish date is very useful, I can't think of when I would want to do that.

Got it, let me handle it then, if you don't mind 🙏

[ericmj]

Please do, thanks!

[elfenlaid]

Please do, thanks!

Hi Eric,

After looking at it more, it looks like that there's no accessible release timestamp for encoded package versions.

The website uses inserted_at as the release timestamp of a package's version: https://github.com/hexpm/hexpm/blob/78e8f9665992de71b22571c7d09fb738fffdd5f3/lib/hexpm_web/templates/package/versions.html.eex#L7

We can extend the protobuf package description with a published_at timestamp: package description: https://github.com/hexpm/hex_core/blob/795c08eff38d0d02a305bede469eb8b3277ddcf7/proto/hex_pb_package.proto#L12-L26

To go into more detail, we can leverage the same trick from a neighbor file https://github.com/hexpm/hex_core/blob/795c08eff38d0d02a305bede469eb8b3277ddcf7/proto/hex_pb_names.proto#L17-L24 or migrate to the third version of protobuf where Timestamp is native, but that's a topic for another day.

---

I'm not sure it would make sense to add the field exclusively for the sake of this issue, but it might be useful in a more broader sense.

If that's the case, then I plan to add an optional timestamp field to the hex_core Package, use that field to populate Package timestamps in the hex_pm, and then use the field to display published timestamps in mix hex.outdated.

It sounds a bit ridiculous for the sake of adding a simple feature as that, but such is life 😅

I wonder if you have any thought, could I have missed something and there's a simpler solution or should I proceed with this one?

[kerryb]

Should this also be an option in mix deps.update? I know I tend to run mix hex.outdated, then mix deps.update --all if there are updates – unless I’m misunderstanding then this would still update everything regardless of whether it appeared as “Update possible”.

[elfenlaid]

Should this also be an option in mix deps.update? I know I tend to run mix hex.outdated, then mix deps.update --all if there are updates – unless I’m misunderstanding then this would still update everything regardless of whether it appeared as “Update possible”.

That's a good point. Alas, I'm afraid that the issue discussion made the issue title somewhat irrelevant.

As where things stand, from my understanding, is that the --cooldown option is out of question. Instead, mix hex.outdated will include the Published column with a package's version release date.

So, only mix hex.outdated should be affected by the issue.

[oshanz]

I came across this ticket while looking for a way to identify inactive or abandoned libraries.
Thumbs up 👍 for including the latest release date alongside the mix hex.outdated visualization.
It would be a great indicator for spotting these packages, because sometimes being on the latest version doesn't mean a package is healthy.
Of course, a package untouched for 5 years may be rock solid with no known vulnerabilities, but there's nothing wrong with taking a extra look.