Node versioning

[Keavon]

Node versioning

[0HyperCube]

This sounds overly complex @Keavon. Could we think about having a system whereby there is only one version of each node for increased simplicity? For example blender doesn't allow users to have different versions of the same node.

[Keavon]

We need some way to let us upgrade nodes without breaking user documents which depend on its proto node and/or document node's network. One situation is when the "signature" of the node changes, and we could induce an upgrade (that's what Blender does). The other situation is when the algorithm itself changes, in which case we need to potentially mark the node as deprecated but still reference the old implementation (particularly its proto node that we'd archive), so as to ensure that users can open documents in the future without the rendered output changing.

This relates to #1609 and the node marketplace, which would essentially be our ecosystem's package manager for both first-party (included out-of-the-box) and third-party nodes. We, and third parties, will need the ability to publish updated nodes (probably using semver). This issue essentially talks about that aspect of the package manager system we'll be building, but potentially an early form of just the versioning system in what will become the full package manager.

Please let me know if you have any questions about that.