Custom Node Testing
Your question
I’ve noticed a discrepancy between the latest GitHub release (0.28.0) and the stable version displayed inside the ComfyUI interface (0.28.3). This raises several questions:
What is the difference between the official release tag on GitHub, the “stable” branch (as shown in the UI), and the master (or main) branch?
Which one should users download for production use, and which one is for testing?
Why are the version numbers not in sync?
this makes it difficult to report bugs, track updates, or understand the development status of the project.
I propose unifying the versioning and branching strategy to make it more transparent and user-friendly. For example:
-
stable – well-tested, production-ready releases (tagged with semantic versions, e.g., 0.28.3).
-
beta or unstable – release candidates or features that are being tested.
-
nightly or dev – latest cutting‑edge changes, possibly with known issues.
All branches should have clear descriptions in the README, and the version number shown in the UI should always match the corresponding tag (or at least indicate the exact commit hash when a branch is used).
This would reduce confusion, improve issue reporting, and make it easier for contributors to know what they are working with.
Additionally, I currently hesitate to update from 0.28.2 to 0.28.3, despite the UI labelling it as "stable". The frequency of these point releases and the growing number of open issues make this version feel far from stable in practice. This further undermines confidence in the current versioning scheme and highlights the need for a clear branch policy that reflects actual development stages.
I also believe that the master (or main) branch should always represent the latest stable code, aligned with the latest release tag. If development needs to happen elsewhere (e.g., in a develop branch), that should be clearly documented. This would make it clear to all users that cloning master gives them a production‑ready version.
Custom Node Testing
Your question
I’ve noticed a discrepancy between the latest GitHub release (0.28.0) and the stable version displayed inside the ComfyUI interface (0.28.3). This raises several questions:
What is the difference between the official release tag on GitHub, the “stable” branch (as shown in the UI), and the master (or main) branch?
Which one should users download for production use, and which one is for testing?
Why are the version numbers not in sync?
this makes it difficult to report bugs, track updates, or understand the development status of the project.
I propose unifying the versioning and branching strategy to make it more transparent and user-friendly. For example:
All branches should have clear descriptions in the README, and the version number shown in the UI should always match the corresponding tag (or at least indicate the exact commit hash when a branch is used).
This would reduce confusion, improve issue reporting, and make it easier for contributors to know what they are working with.
Additionally, I currently hesitate to update from 0.28.2 to 0.28.3, despite the UI labelling it as "stable". The frequency of these point releases and the growing number of open issues make this version feel far from stable in practice. This further undermines confidence in the current versioning scheme and highlights the need for a clear branch policy that reflects actual development stages.
I also believe that the master (or main) branch should always represent the latest stable code, aligned with the latest release tag. If development needs to happen elsewhere (e.g., in a develop branch), that should be clearly documented. This would make it clear to all users that cloning master gives them a production‑ready version.