Closed longfin closed 1 year ago
Versioning can help serializing & execution on various versions of actions. but it can't help if target action relies on other classes and game dev also updates it. In this case, we should versioning all of them. :confused:
To handle this problem well, maybe we need to versioning on .NET assembly level, not action class level. The .NET ecosystem seems to support tools like AppDomain
(pre .NET Core) or AssemblyLoadContext
(.NET Core 3+) for isolated loading of assemblies.
Libplanet's "action"s(implementations of
IAction
) are tagged byLibplanet.Action.ActionType
attribute for serialization.
In this topic, you mean only PolymorphicAction<T>
, not the whole IAction<T>
, right?
In this topic, you mean only
PolymorphicAction<T>
, not the wholeIAction<T>
, right?
Right, I've confused.
In this topic, you mean only
PolymorphicAction<T>
, not the wholeIAction<T>
, right?Right, I've confused.
But, I also believe all actions including not PolymorphicAction<T>
need versioning feature as migration mechanism too.
This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.
Libplanet's "action"s(implementations of
IAction
) are tagged byLibplanet.Action.ActionType
attribute for serialization. but sometime, some "action"s perform different actions as they are upgraded, and the serialization format is different for this. at this time, if the serialization type of an action tagged with theActionType
is changed, serialization and deserialization may fail.The simplest way to avoid this is to specify a new
ActionType
each time.(e.g.ActionType("hack_and_slash_v13")
. but If we provide dedicated primitives(e.g.Version(13)
) for specifying the version, we might be able to distinguish it more meaningfully.Furthermore, it may be possible to store bytecode(CIL) according to the version if necessary.