RFC Discussion: RFC: Custom Nodes Dependencies Management

[github-actions[bot]]

This is the discussion thread for RFC PR #31.

Please provide feedback and discuss the RFC here rather than in the PR comments.

PR Link: #31

[webfiltered]

I think we can also use this for use with the concept of "custom node tested to work with Comfy Version x.x.x". The idea behind that is that we show the highest versions that an extension is known to work with, in the registry / manager.

That should result in less confusion when trying to install an old, abandoned extension. It will also allow a notification of which extensions are potentially incompatible with an updated Comfy version.

I think version ranges are important, but should always have an upper limit (the current version at time of writing). For example an extension may have all the following be true:

Written for version: 3
Minimum version required: 2
Works with version: 4

So its version range is 2-4. If not specified, the upper limit could be extrapolated (as "unconfirmed") to whichever version was latest stable when the .toml file was last modified.

Possibly outside the scope of this RFC, but I also want a mechanism that allows the community to flag in registry / manager that an extension works with e.g. the latest Comfy version (without updating every .toml every version).

[christian-byrne]

I am 100% in support of this and think we will do it soon -- just a matter of implementation details.

I'm wondering how necessary this part is? Is the suggestion just that the frontend and comfyUI better follow semver principles when determining how to increment version number?

rfcs/rfcs/0000-custom-nodes-dependencies-management.md

Lines 51 to 64 in 013b8e5

	### Core Component Versioning
	For this system to work, ComfyUI core components need clear versioning. We propose:
	1. Core components (Frontend, Core, etc.) should each have their own version number
	2. Each release with breaking changes must include detailed information about those changes in the release notes.
	3. A separate, dedicated document should be maintained to track all breaking changes across versions. This "Breaking Changes Log" should include for each entry:
	- **Date**: When the breaking change was introduced
	- **Pull Request**: Reference to the PR that implemented the change
	- **What Changed**: Detailed description of the change
	- **Reason**: Explanation of why the breaking change was necessary
	- **How to Fix**: Guidance for custom node developers on updating their code
	This documentation approach ensures that custom node developers can easily understand what changed between versions and how to adapt their code accordingly, while the dependency specification system provides a way to communicate these requirements to users.

It seems that when something breaks, the process will naturally go like:

1. Custom node dev discovers breaking change
2. They release a new version with the fix
3. In that release, they update the ComfyDependencies property in pyproject.toml, establishing a clear demarcation.

[christian-byrne]

Linking the task for visibility: https://www.notion.so/drip-art/Comfy-Registry-Add-compatibility-metadata-1f66d73d3650804f93cedee00c31150f