When do we create pull requests?
Did you ever wonder when Depfu will send you the PR for a new version?
We haven’t been super transparent about that in the past as we were also experimenting with different strategies. But one major theme has become apparent: we’re not that interested in real-time. We think updating as soon as possible after a new version gets released rarely make sense. When it does make sense we do send you updates right away and when it doesn’t, we now allow you to control it yourself.
There are a few layers of latency when it comes to new releases in Depfu:
When do we detect new releases?
Only very few registries support webhooks for new releases, so we unified on polling registries regularly instead. We do check public registries every 15 minutes and private registries every 30 minutes. That means at the latest 30 minutes after a new version is released, we’ll have it in the system.
When do we run new releases?
We differentiate between detecting releases and running them. Running means we start creating pull requests for repos using that package.
Pretty early on we noticed two patterns around releases:
- The quick bugfix release: Often after major versions, but also in other cases the maintainer notices themselves or gets bug reports about some major problem right away. Within hours there will be a new release, sometimes more than one. This is not a problem in itself, but it created a lot of noise in your pull requests, as we would open and close several PRs in short succession.
- The yanked release: If the maintainer overlooked something major and doesn’t have time to fix it right away, they usually yank the newly released version. Which means if you updated right away, you’re now using a yanked version.
We looked at the data we had and realized that waiting for 24 hours before creating the pull request would avoid a lot of these cases. So that’s what we do: If a new version comes in before the 24 hours are up, it’ll supersede the older version and we will wait 24 hours again before we run it. For packages that release daily we do make sure to run at least one release a month.
Our reasonably-up-to-date strategy is another layer on top of this. Since it highly depends on the package and its release frequency, we can’t really predict when we will run it. But we always wait at least 7 days and at most 30 days.
By using this strategy you’ll also have a bit of a buffer, which can come in handy for releases containing malware or similar issues, which often take some time to get detected.
When not to wait
There are a few cases where waiting doesn’t make sense and you want to get the pull request as soon as possible:
- Security releases: Of course, when a release fixes security vulnerabilities waiting clearly doesn’t make sense. As soon as we know about it, we will run the release right away and not wait at all.
- Private packages: With public packages waiting doesn’t really affect you since you don’t know when the new version was released in the first place. So it doesn’t feel like waiting, the release just comes in. Private package are different, since you do the release yourself and you know it just happened. You usually do a release of a private package because you want to update a specific project or all projects with that new version. As of today you can trigger updates from the releases page for all your repos or a single one. This way you have full control if you want to wait or not.
The new releases page
To give you more visibility and control into all of this we build a new page, showing you what’s happening for your org:
It allows you to:
- See which releases we have already detected and when they will run.
- Run those releases early for all your repos or just a single one.
- Trigger a check of your private registries for new releases. For when you know you just released a new version and want it rolled out right away.