Why let releases ripen
A version published an hour ago has had no time to be noticed, reviewed or pulled. Ripedeps waits a number of days you choose before it proposes a release. That costs little and removes the freshest, least checked versions from your tree.
The newest release
Updating to "the latest" means taking whatever was published last. That release has been seen by the fewest people: nobody has had the time to report a regression, to spot a hijacked account or to publish a fixed version. A short wait gives the registry and the community that time, at no cost to you except a few days.
Most of the time nothing is wrong and the wait only delays a harmless update. The gate is a cheap habit, not a prediction about any single release.
What the gate does
The age gate is the setting minAgeDays. A version is only a candidate if it was published at least that many days ago. Younger versions are not considered at all, so they cannot end up in the file you get back.
With a gate of 7 days, only the versions left of the line can be proposed. When a newer release exists, the explanation of the package says what was left out and why. A real answer from the service, with a gate of 7 days and major upgrades allowed:
next 15.0.0 -> 16.4.2 (major step, 8 days old, age gate 7); newest version that qualifies; not taken: next@16.4.3 is 0 days old, the age gate is 7 daysThe version you already have always stays a candidate. The gate never moves a package backwards, even when the version in your file is younger than the gate.
Choosing the days
There is no number that is right for everyone. The web tool offers 0, 3, 7, 14 and 30 days, and the API and the script accept any value from 0 to 365. As a starting point:
| Days | Reasonable when |
|---|---|
0 | You need the newest version that qualifies today, for example a fix you must take now. |
3 | A short pause for projects that update often and have good tests. |
7 | The default of the web tool and the number to start with. |
14 | Projects that prefer to be a little behind than to be first. |
30 | Cautious projects that change rarely, or where a bad update is expensive. |
A longer gate leaves more recent versions out, so the packages stay further behind the newest release. Shorten it when you want to catch up, lengthen it when stability matters more.
With the other rules
The gate is the first filter on the candidate versions. The step size and the constraints between packages then work on what is left. So a package can be held back for a second reason: the newest old-enough version may be too big a step, or it may not fit the peer range of a neighbour. The explanation always names the first reason.
The gate also applies to the packages that are moved together. Packages that are moved together are all chosen from old-enough versions (the version already in your file is the one exception), so one very young release cannot drag its neighbours along.
What it is not
- It is not a vulnerability scanner. Ripedeps has no CVE data and does not know which versions are affected by anything.
- It is not a guarantee. A bad release that stays unnoticed for longer than the gate still passes. The gate lowers the chance of being among the first to install it.
- It has no per-package exception. To take a fix today, run Ripedeps with a gate of 0 days, or with a focus on that one package.
Your lockfile, your review process and a vulnerability scanner still do their own jobs. The age gate is one more layer in front of them.
Using it
The setting is the same everywhere: the age selector in the web tool, minAgeDays in the API and the MCP tool, and --min-age in the script. To keep it with the project, put it in your package.json; a request that sets it explicitly wins.
"ripedeps": {
"minAgeDays": 14
}Still have questions? See the FAQ, or try the gate on your own package.json.