[GH-ISSUE #202] Branching feature request #108

New issue

Closed

opened 2026-10-27 21:13:13 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

2026-10-27 21:13:13 +00:00

Owner

Originally created by @Nourepide on GitHub (Nov 30, 2023).
Original GitHub issue: https://github.com/Comfy-Org/ComfyUI-Manager/issues/202

Hi, there will be a split of the Allor plugin branches in a few days.

Current functionality will be moved to the v.1 branch, and the main branch will be used to develop Allor 2 which will break backwards compatibility.

Users will of course be notified in the terminal that this branch is "unstable" with a message, but I think it's worth somehow separating Allor 1 and Allor 2 in the user manager so as not to confuse them.

I decided to ask for your help and figure out how to make it more convenient for the manager users.

Originally created by @Nourepide on GitHub (Nov 30, 2023). Original GitHub issue: https://github.com/Comfy-Org/ComfyUI-Manager/issues/202 Hi, there will be a split of the Allor plugin branches in a few days. Current functionality will be moved to the `v.1` branch, and the `main` branch will be used to develop Allor 2 which will break backwards compatibility. Users will of course be notified in the terminal that this branch is "unstable" with a message, but I think it's worth somehow separating Allor 1 and Allor 2 in the user manager so as not to confuse them. I decided to ask for your help and figure out how to make it more convenient for the manager users.

bsakaguchi closed this issue

2026-10-27 21:13:13 +00:00

bsakaguchi commented

2026-10-27 21:13:14 +00:00

Author

Owner

@ltdrdata commented on GitHub (Dec 1, 2023):

Oh, this is quite a challenging issue. We've had a similar case before, like when ControlNet was renewed to ControlNet Aux and when the maintainer changed from Efficient Node to Efficient Node V2.0.

As complete backward compatibility is broken, one approach is to separate the repositories. If you want to allow access to the existing custom nodes, a method like this to split the repository could be considered. In this case, I would take the step of moving the existing Allor 1 repo to a legacy channel.

@ltdrdata commented on GitHub (Dec 1, 2023): Oh, this is quite a challenging issue. We've had a similar case before, like when ControlNet was renewed to ControlNet Aux and when the maintainer changed from Efficient Node to Efficient Node V2.0. As complete backward compatibility is broken, one approach is to separate the repositories. If you want to allow access to the existing custom nodes, a method like this to split the repository could be considered. In this case, I would take the step of moving the existing Allor 1 repo to a legacy channel.

bsakaguchi commented

2026-10-27 21:13:14 +00:00

Author

Owner

@Nourepide commented on GitHub (Dec 2, 2023):

Thanks for the reply.

It is too early to call Allor v.1 legacy, I would say it is stable as opposed to the unstable Allor v.2.

However, Allor can switch branches by itself to the one specified in the config. I guess I'll just wait a while for users to notice the message in the terminal before changing some nodes.

In that case, after v.2 development starts, I will send a Pull Request with the Allor description change to warn the manager users.

Again, thanks for the reply, I'm closing this Issue.

@Nourepide commented on GitHub (Dec 2, 2023): Thanks for the reply. It is too early to call Allor v.1 legacy, I would say it is stable as opposed to the unstable Allor v.2. However, Allor can switch branches by itself to the one specified in the config. I guess I'll just wait a while for users to notice the message in the terminal before changing some nodes. In that case, after v.2 development starts, I will send a Pull Request with the Allor description change to warn the manager users. Again, thanks for the reply, I'm closing this Issue.

bsakaguchi commented

2026-10-27 21:13:14 +00:00

Author

Owner

@ltdrdata commented on GitHub (Dec 2, 2023):

Thanks for the reply.

It is too early to call Allor v.1 legacy, I would say it is stable as opposed to the unstable Allor v.2.

However, Allor can switch branches by itself to the one specified in the config. I guess I'll just wait a while for users to notice the message in the terminal before changing some nodes.

In that case, after v.2 development starts, I will send a Pull Request with the Allor description change to warn the manager users.

Again, thanks for the reply, I'm closing this Issue.

In that case I can add Allor 2 to dev channel.

@ltdrdata commented on GitHub (Dec 2, 2023): > Thanks for the reply. > > It is too early to call Allor v.1 legacy, I would say it is stable as opposed to the unstable Allor v.2. > > However, Allor can switch branches by itself to the one specified in the config. I guess I'll just wait a while for users to notice the message in the terminal before changing some nodes. > > In that case, after v.2 development starts, I will send a Pull Request with the Allor description change to warn the manager users. > > Again, thanks for the reply, I'm closing this Issue. In that case I can add Allor 2 to dev channel.

bsakaguchi referenced this issue

2026-10-27 21:28:18 +00:00

[PR #108] [MERGED] Add variation seed and weight #1183