Version attribute

[Jake]

Hi,

I'd like to have a version attribute to add to my custom actions, something like [Version("1.0")], also this could possible be shown in the action browser. This way it would be easier for me and my customers to ensure we're using the same version of the script (as custom actions packs are usually a separate download).

Of course I can add a version to my package name, but having it sticked to the action would be cooler. Additionally, this would be needed for any future repository plans anyway.

Jake

[escpodgames]

Wouldn't it be easier to give your customers a package with all the actions you're using?

[Jake]

I do so, but as each action is an independent class a version sticking to that class would be more convenient in my opinion.

[jeanfabre]

Hi,
 
 I am very much interested on this aspect of versionning actions, this is a problem for me as well, and it's not even been addressed with standard scripts actually... so not sure it will ever be manageable within PlayMaker.

I think that the key to this would be to separate the name of the action and the name of the class itself, making a complete distinction of them two aspect will allow any kind of versionning system, because then the class itself can be named differently, like "SetPosition_v2", YET the name that would appear in the action browser and in the state would still be "SetPosition" and we could have some visual feedback with a smalle "V2" colored tag or something.

This could be easily achieve if we can have access to the actual name to display for a given action. Since we can already modify the name of an action within a state, I think we would not be far from this ability.

This is something that I am really trying to nail down in my head, cause it's been discussed a lot that an ecosystem to access cusotm actions would be welcome, and indeed versionning will be a very important aspect. There are two type os versionning for actions,

-- A change of public interface, that's the most dramatic versionning aspect, as it affects the way you set it up. that's where a different class name would be required in my opinion

-- A Fix or improvement in the behaviour itself, that's already a minor versionning, like fixing a case not handled properly on an existing action, nothing changes, it only improves. Class name can remain unchanged here.

 Bye,

 Jean