Hi HN, we’re Steve, Allison, and Andy, founders of Infield (<a href="https://infield.ai">https://infield.ai</a>). Infield makes it clear which open source dependencies you should upgrade next, and how to do so safely. We do this by using a LLM to read every changelog.<p>Here’s a short demo video: <a href="https://www.youtube.com/watch?v=diCGmtMUeRU">https://www.youtube.com/watch?v=diCGmtMUeRU</a><p>We’re launching today with support for Ruby packages. If you’ve ever run `bundle outdated` or upgraded a Rails app, Infield is for you. You can try it on your own project at <a href="https://app.infield.ai/hn">https://app.infield.ai/hn</a>. Upload your Gemfile and Gemfile.lock (no email/name/cc required) and we’ll show you Infield on your code.<p>I (Steve) have been building open source software and commercial web apps for more than a decade. I spent the last year personally upgrading Rails apps by hand for companies in order to research this problem. I'm convinced that every company is re-inventing the wheel and doing by hand a bunch of toilsome work that can be done with software.<p>As one example, I was working as a consultant upgrading an app to Rails 7. This company was using the attr_encrypted gem to encrypt information at the database level. Rails 7 brings built-in support for encryption in a way that's incompatible with this gem. Having hit this same problem at two other companies I already knew how to handle the migration; but if I hadn’t, they could have risked their most sensitive customer data (this is what you tend to encrypt). After that project I started building a personal database of "upgrade experiences" and before long felt sure we could make useful software.<p>The time-consuming part of package upgrades is not coding—it’s mostly risk assessment, research, and project planning. If I’m on a maintenance rotation and have half a day to pay down some technical debt, which package upgrades should I look at? I might end up spending that time trying to upgrade something only to get blocked and give up. Worse, many breaking changes are subtle and won’t be caught by CI. I’ve brought down production only to find an issue was buried in a changelog I didn’t read!<p>Infield scans all of your dependencies to prioritize upgrades based on effort (how much work is this? Is it risky?) and impact (will upgrading fix a security issue? will it get me onto a supported branch?). We can do this because we use GPT to read the changelog for every package you rely on. Changelogs are broken apart into discrete changes and classified according to the keepachangelog.com standard. Then a human expert reviews the output. We can spend more time researching each package than you because we’re going to re-use this work for every future customer doing the same upgrade.<p>Sometimes you want to do a complex upgrade like Rails that might be blocked on other packages being upgraded first. For this case we run an optimization based on the PubGrub
algorithm to solve for a suggested target version of all your dependencies that will be compatible with the next version of Rails. We group and order these blockers into an "Upgrade path" you can follow.<p>Most of the existing work in this space is security monitoring software like Dependabot or Snyk. These tools are primarily sold to security teams to let you know about CVEs that affect your dependencies. They’re reactive, a way to let developers know when they need to upgrade something but not how to do it. Our goal with Infield is to make it so easy to keep dependencies up to date that you’re always on the latest versions.<p>Infield is $60/mo/repo and we’re launching today with support for Ruby. Javascript and Python are probably next, but we’re very interested to hear which language you feel this pain in most acutely. Ruby is first since the consolidation around Rails allows us to really nail the experience for a focused set of packages.<p>You can try Infield on your own codebase at <a href="https://app.infield.ai/hn">https://app.infield.ai/hn</a>. With the paid plan we’ll hook into your codebase to continuously scan your dependencies as you merge PRs. That works via a Github app, or you can use our CLI tool to send us just the files we need as part of your CI pipeline.<p>Please give it a try and comments are welcome! We’d love to hear everything you hate (or love, or just think) about dependency management and how we can make it better!
Ruby is nice, but if you were to actually solve this problem for Python you'd print money. The deluge of knowledge required to actually navigate Python dependency management across all major OS's for the most complex use cases (typically ML stuff with deep compiler/tool chain deps) is nothing short of a nightmare. Especially on Windows, the rage I feel towards MSVC knows no bounds. venv, pip, (mini)conda, mamba, poetry, apt, yum... Obviously the last two are good to know anyways, but ugh the hours I've lost and will never get back to the rest.<p>Anyways, god speed my dudes.
I don't think the fundamental thesis makes sense. The most time consuming part of package upgrades is most definitely coding. When a dependency gets a CVE it isn't an optional upgrade we can do somewhere down the line when it's convenient. We have to do it by the next scheduled release, or worse, before the next scheduled release. Regardless of the package, there's always changes, some of them breaking, which take considerable effort not only to implement and test, but also to identify in the first place. That's where the difficulty lies, not in planning when to upgrade what.
I clicked into this because I was excited, but everything feels like it's missing the mark for me. And, that pricing. Woof. That's steep for being a fancy changelog interpreter.<p>----<p>My biggest pain isn't with the plan. It's with the actual upgrade process. Things _always_ break. Every single time we do a major upgrade, there's this long tail of things we need to fix. Even worse is the undocumented changes that break. This gives me nightmares.<p>The problem with your product is four parts:<p>* It needs to solve much more of the problem. It's not really valuable to know that I need to change stuff. I can figure that out by running my package managers update tool and seeing what breaks.<p>* When things break, it's unbelievably time consuming to fix them. Even worse is the person tasked with doing the upgrade is likely not the subject matter expert on broken code.<p>* I need to know what's broken that wasn't documented. This is by far the hardest part of our upgrade cycles. It keeps me up at night knowing a major upgrade could break things that aren't covered by unit tests.<p>* Because dependency upgrades are so hard, we tend to do them in large swoops. We set aside a week or two of pain and power through them. Given you're charging $60/m, this suggests:<p><pre><code> * Your model is more aligned with small, continuous upgrades. Once you're "close" to the most recent version, it tends to be easier to upgrade.
* Your model needs a better way to "gain pace" with the latest releases. If I can incrementally upgrade one package on every PR until I'm up to date, that'd be amazing.
</code></pre>
-----<p>I think this tool would be extremely value to me (likely $60/m/repo) if it:<p>* It ran the repo's test suite against progressively newer versions of dependencies. Showing when and where unit tests fail.<p>* Provide some means of "intelligent E2E" testing. Fire up our API/application. Tell us what changes when dependencies are upgraded.<p>* Fan out broken code to the subject matter expert. If an upgrade from X to Y is broken, look at the `git blame` to figure out who knows how to fix the code. Ping them asking them for help.
How are you computing upgrade paths? This seems impossible to do accurately, especially for Ruby, since you can't simulate the user's build's dependency resolution given that Gemfiles are dynamic.
Very cool! Is the LLM-on-the-backend a recent addition or have y'all been thinking about that potential since 2020? Would be curious to hear a bit more about your journey to market
Congrats on the launch!<p>The dashboard looks really well done, especially the path identification.<p>I'm curious why you decided to start with Ruby. Anecdotally, it doesn't seem as big of a problem as other languages with either (a) more upgrades or (b) worse package managers.<p>Disclosure: I'm the cofounder of <a href="https://grit.io" rel="nofollow">https://grit.io</a> which also does some dependency management, but focused on automating the actual code changes.
Sounds a bit like the Renovate bot <a href="https://docs.renovatebot.com/" rel="nofollow">https://docs.renovatebot.com/</a>, but with LLM changelog parsing.<p>I started using Renovate on a few project recently and I am impressed. Not quite yet to the point of letting it merge dependency updates for me, but for unearthing them and creating a pull request (after which my tests run automatically) is already a big help.
How does this differ from Github Dependabot? Here's an example of vulnerability it found recently: <a href="https://github.com/advisories/GHSA-hj3f-6gcp-jg8j">https://github.com/advisories/GHSA-hj3f-6gcp-jg8j</a>. And this is free.
Maybe it's just me but this wording seems weird to me, not sure why exactly:<p>> World-class Engineering teams use Infield to make dependency maintenance time twice as productive.<p>Specifically, "to make dependency maintenance time twice as productive." Feel like it ought to say "to cut the time they spend maintaining dependencies in half". I know that's wordier and maybe that's not quite it, but the wording as is feels a bit tortured to me.
What I would love to be standard in all product launches like this would be to have a mailing list per integration or, as with this, programming language.<p>I want to be able to drop my email address and only hear back when support for $MY_FAVE_LANG is available.