Plugin's new version best approach

Hello :slight_smile:

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?

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

1 Like

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.

1 Like

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
1 Like

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 :slight_smile: