Best practises for handling newer custom component versions

[Christos_Tsaridis]

I am wondering what the best practises for handling custom components in newer plugin versions are. If a custom component was placed in an existing script and in a later plugin version this component has been modified, for example its name, some parameter descriptions etc, this component will show exactly the same as before unless it is deleted and replaced manually by the user. This does not make for solid user experience.

What I would like to find out is:

1. I know it is possible to query the plugin’s version in GH, but is it possible to query a component’s version? If not, I am thinking it may be a good idea to persistently store the plugin’s version on every component so that it can recognise if a newer plugin version was released so it can do something to update itself.

2. What would that something be? At the very least it could be a warning message stating that the component placed on the canvas needs to be manually replaced so that the newer version will properly show. Even better would be to have the component automatically replace itself on the canvas, which might however open a whole other can of worms.

Could you share your thoughts / experience on this issue?

[ondrej (Ondrej Vesely)]

If you need to just update the component and parameter instances names / descriptions, you can use the “workarounds” discussed in this topic.

The more correct way component versions are supposed to be handled is:

1. Each version of the component is it’s own separate class in your project. Make sure it uses an unique ComponentGuid.

2. Add public override GH_Exposure Exposure => GH_Exposure.hidden; and public override bool Obsolete => true; to the older versions. These overrides will hide the component from menus and add OLD tag over the icon of the existing copies.

   

3. Add a class implementing IGH_UpgradeObject to enable the users to automatically update any instances of old versions to the new version.