Preamble: I'm aware of the "deprecation" mechanisms for nodes. My problem is more in the opposite direction, or a special sub case:
(1) I've a Plugin v1.0 with various nodes
(2) I'm developing Plugin v2.0 which will become much better. One of the existing nodes gets an additional setting in the configuration, let's call it “[ ] Append column with value XYZ“. But the existing behaviour of the node does not change, it is 100 % backwards compatible to v1.0 (so, I see no reason to @Deprecate it, instead I simply add to the existing implementation)
Now the issue:
(3) User A creates a workflow using v2.0 of the nodes, and checks above mentioned option “[ ] Append column with value XYZ“
(4) User B opens this workflow, but he’s still using v1.0 of the nodes. Upon resetting and re-executing the node with the option added in v2.0, the resulting column will not contain the additional column and downstream nodes will fail.
Until today, I expected that opening a workflow which was created using a newer version of some nodes than currently installed would trigger a warning message. Upon my tests, this does not seem to be the case? So user B will probably not be aware that there's a v2.0 available.
(a) Just to clarify: KNIME performs no checking and warning about the node versions upon opening a workflow? Or am I missing something?
(b) Code wise, I would really like to avoid having to deprecate and adding a new copy of a node every time there are additive changes which do not break existing functionality. (the mentioned node in the scenario above is actually an abstract superclass, so I would have to deprecate the entire inheritants).
(c) Are there any general best practices for such a case?
Best,
Philipp