Plugin's new version best approach

[w.radaczynski]

Hello

I wanted to ask what is the best approach in your opinion to avoid a situation, when the user has old GH definitions that were made with an old plugin version, and then he switches to the new version of plugin, that behaves differently.
Should I create a new GUID everytime for all of the components to make sure, that he will not be using the new version of plugin in an old scripts that was made with a previous version?

[Will_Wang]

I’d make a new component (new guid) and mark the old one, as suggested in the following post

Question custom components

Name the class with _OBSOLETE So something like public class Component_ConstructPoint : GH_Component would become public class Component_ConstructPoint_OBSOLETE : GH_Component That will make it have the “old” tag written over the component icon Then set its exposure to hidden so it only comes up when searching with # You can find all GH old components by searching with # so for instance in this case you can search #ConstructPoint to still get access to it in gh. For that you do: pu…

[gankeyu (Keyu Gan)]

I mark old components as obsolete. Though if the change is quite minor, such as change of default setting, but breaks something, my plugin tracks version when the file is stored and components will mimic old behaviors if so.

[Michael_Pryor (ekim)]

What I usually do,

Obsolete the old component and make a new one (with new GUID) if:

1. The behavior changes
2. The amount, types, or order of inputs / outputs changes
3. Default values change

Don’t make a new component if:

1. You are just fixing bugs or improving performance (but the results are the same minus no more bug)
2. You change descriptions or icons or names
3. You change the location of the component in the tabs

[w.radaczynski]

Thank you @Will_Wang, @gankeyu, and @Michael_Pryor, there is a lot of useful information. It’s quite interesting also, because if I understand correctly, you can have then multiple old components with “Old” tag, that you cannot delete to don’t break someone’s old scripts.

Also your approach will probably work great when you have all of the actual logic of component inside it. I wonder how it will behave, when you have this logic divided between the component template and some classes in the different project, that you are using. With this division it will be much harder to update those classes in the other project, cause you can’t just copy the component with all of the logic, and mark old one as “Old”.

Thank you for suggestions