Mess with stable versions

### Custom Node Testing

- [ ] I have tried disabling custom nodes and the issue persists (see [how to disable custom nodes](https://docs.comfy.org/troubleshooting/custom-node-issues#step-1%3A-test-with-all-custom-nodes-disabled) if you need help)

### 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.

Compare the GitHub 0.28.0 release tag with the stable version shown in the UI and the stable and master branches. Review the README and the project's release/versioning references first. Done means the branch roles, production/testing guidance, and version-to-commit relationship are documented clearly enough for users and contributors to identify what they are running.

Written by the indexing model from the issue text.