Updating a Module

[Centripidity]

Am I right in assuming that, if I get a new build of an already published module, approved and then publish it to the store, that it will just replace the old version and be automatically available to anyone who owns the earlier version? Assuming I don't change the Package Name.

[utdgrant]

The new build will have to go through the approval process again.

However, once you publish the approved new build, it will automatically replace the old version in everyone's library.

[Centripidity]

The new build will have to go through the approval process again.

However, once you publish the approved new build, it will automatically replace the old version in everyone's library.

Thanks. That what I thought but I wanted to make sure as I promised a user (I think it might have been you ) that the next build would be a free upgrade so I didn't want to get it wrong.

Peter

[seal58]

A new module build is not only be used to fix bugs. Sometimes it is also used to add features to the module. In this case a manufacturer should strictly let basic functions untouched. Otherwise existing presets might not work on other user's computers anymore.

Sometimes there is a need to publish a module to VM, in order to test it under real conditions. Therefore it is helpful to publish the module, that has to be tested, as extra product with different name. That allows still to use the older version in own presets and to compare both versions to each other.

When that "test product" is not needed anymore, one can delete it, because it was not published to store yet.

Roland

[Centripidity]

A new module build is not only be used to fix bugs. Sometimes it is also used to add features to the module. In this case a manufacturer should strictly let basic functions untouched. Otherwise existing presets might not work on other user's computers anymore.

Sometimes there is a need to publish a module to VM, in order to test it under real conditions. Therefore it is helpful to publish the module, that has to be tested, as extra product with different name. That allows still to use the older version in own presets and to compare both versions to each other.

When that "test product" is not needed anymore, one can delete it, because it was not published to store yet.

Roland

Roland, thanks.

If I understand correctly, I can (locally) publish as many builds of an existing publicly published module as I want and they will appear in my personal copy of VM but not in the CA store. That makes it possible for me to test the new versions.

When I have a new build submitted and approved it will replace the old build in users' copy of VM so long the newly published build has the same package name.

I'm not sure how it works with beta testers so I will check. Do they see only the builds that I have set for beta testing, and not any new dev builds that I might create or does making a new dev build remove the beta build from view? It removes it from the beta folder in my CA account but what about the accounts of beta testers? I'll ask my beta tester and find out what he can see.

[honki-bobo]

A new module build is not only be used to fix bugs. Sometimes it is also used to add features to the module. In this case a manufacturer should strictly let basic functions untouched. Otherwise existing presets might not work on other user's computers anymore.

Also keep in mind that - in order to remain "backward compatible" to already created patches - you must retain the "Internal Name" of a component (jack, knob, button, etc.), because the internal name is used to store connections and values with the preset.

[Centripidity]

A new module build is not only be used to fix bugs. Sometimes it is also used to add features to the module. In this case a manufacturer should strictly let basic functions untouched. Otherwise existing presets might not work on other user's computers anymore.

Also keep in mind that - in order to remain "backward compatible" to already created patches - you must retain the "Internal Name" of a component (jack, knob, button, etc.), because the internal name is used to store connections and values with the preset.

Thanks, that’s good to know.

[Steve W]

Thanks for bringing up the backward compatibility issue which implies that consumer-oriented thought should be given to new builds v. new versions when existing features are changed and new features are added. VM users can spend considerable developing patches on top of serious financial inventments and if module makers are aren't mindful about breaking existing modules when they make changes, that could affect not only their reputation, but VM's reputation as well.

[Centripidity]

Thanks for bringing up the backward compatibility issue which implies that consumer-oriented thought should be given to new builds v. new versions when existing features are changed and new features are added. VM users can spend considerable developing patches on top of serious financial inventments and if module makers are aren't mindful about breaking existing modules when they make changes, that could affect not only their reputation, but VM's reputation as well.

Steve, is there any guide to help implement this? I assume it's about the stored/retreived State Information and the VMD documentation suggests they are using a Properties object.

My assumption is thus that you can add State Information (controls etc) to a new version without causing compatibility issues so long as none of the instance names are changed between builds. I base that on the further assumption that when the new build loads State Information the VM internal code can deal with not finding values for new controls in old presets. Is that a reasonable assumption?

And of course, any custom State Information your module uses must be able to handle backward compatibility with presets.

Are there other issues that need to be dealt with?

Peter

[utdgrant]

My assumption is thus that you can add State Information (controls etc) to a new version without causing compatibility issues so long as none of the instance names are changed between builds. I base that on the further assumption that when the new build loads State Information the VM internal code can deal with not finding values for new controls in old presets. Is that a reasonable assumption?

I can state that this is the case. I've added new controls to an existing module (a new switch and new LEDs to Big Rat). All existing preset patches loaded without a problem. I can't comment on whether "Module Presets" (i.e. right-click, save-as) work in the same way, as I never use that functionality.

However, I've never removed any controls when creating a new build. I think this would be a recipe for disaster, for many reasons.