New Lifter Improvement: Recommended Release Package Dependencies

#1

As part of your lifter tasks, we ask that you keep your master branch of your GitHub repository up-to-date dependencies-wise (if you have a GitHub repo for your project, of course!). Dependencies in your released packages will slowly go out-of-date depending on how you referred to them in your manifests, and the interactions of multiple packages requiring different, older versions of dependencies can create a “dependency hell” situation for subscribers. To help reduce this possibility, we’ve started checking the dependency requirements of the latest release of your packages that we’re suggesting to subscribers:

What version are we recommending to subscribers? If you are recommending “Only the latest version” of your package, it’s the most recent non-prerelease package. If you’re marking up release streams with LTS, deprecated, or prerelease information, it’s the most recent non-prerelease version in the highest active or LTS release stream:

Once we have the recommended version, we’ll be checking that release’s dependencies in your package’s manifest files, with info provided by Libraries.io. Libraries.io currently does a basic check to see if a dependency is out-of-date:

fbe26e8f1d8dbf30df8294e8b75105a6

If you’re using another lifted package as part of your dependencies, that dependency will get the same detailed check subscribers receive. If any of your released packages’ dependencies become out-of-date, all you have to do is release a new version with an updated manifest specifying new versions and we’ll mark the task as complete.

This functionality is still new, so we’re looking for your feedback on it. Once the task is working as intended, we want to expand it to checking the latest version in LTS release streams, so that subscribers on older versions can still stay up-to-date. Thanks!

1 Like