Need Advice: Hex Package release plan & cadence

TL;DR;
Best practices for shipping an ecosystem of connector packages to Hex in a responsible way?

Background
I have a project, jido_connect: GitHub - agentjido/jido_connect: Integration and connector framework for Jido host applications · GitHub

It is a library of Jido Actions and Primitives for connecting Jido Agents to services such as Google Workspace, Github and Notion.

The project is organized around a base hex package: jido_connect and then adapter packages, such as jido_connect_google. The list of packages is growing - I’m up to 30 plus connector packages.

I have NOT published any of the jido_connect packages to Hex yet. I am cautious to simply ship 30+ packages due to the (personal) commitment to maintain them. The code is being used in my personal projects and in several Jido ecosystem projects - I’d consider it a reasonable BETA quality.

My Hesitation
Personally, if I ship a package to Hex, I’m committing to maintaining it (unless I formally deprecate it). I’ve done this across the Jido ecosystem and am already managing several packages.

I also don’t want to be spammy to Hex and I don’t want to create such a surface area that the maintenance burden becomes overwhelming.

On the contrary, there are users of this code that would like to have Hex packages in a few limited cases. The base package with the DSL and shared behaviours (jido_connect) is a good candidate - with the guidance to then either add dependencies via Hex or vendor the code.

Thoughts?

2 Likes