Difference between deprecated and legacy nodes

[myxiao]

Dear KNIME community,

Many KNIME nodes are labelled as “deprecated” or “legacy”. I want to ask about the difference in their definitions.

I noticed that in the “Noding Guideline” of KNIME, deprecation is clearly defined:

Backwards Compatibility: Nodes whose settings have changed from one version to another (more or different configuration possibilities) should be backward compatible. If possible the new version should provide default values for the new settings fields. These default values should cause the previous behavior of the node, and avoid exceptions if the new value cannot be found in the settings. If it is not possible to make the new version backward compatible with the old version in the way described above, the old version of the node should be moved into an extra plugin (deprecated) or put into a separate source folder (e.g. “src-deprecated”) and removed from the node repository. The new version should be registered to the node repository. Using this mechanism, old workflows will load, because the old node can be found in the deprecated plugin, but all new workflows will use the new version, since there are no means to use the old version of the node in the GUI.

Nodes that should not be used in new workflows any more (e.g. because there is a better replacement or they computed wrong results) should be deprecated.

Unfortunately, I have not yet found an official definition of “legacy” nodes, and whether they are also designed to be backward compatible.

In addition, I would also like to know what it means when a node is labelled as both “deprecated” and “legacy”.

Thank you so much!

[nan]

Hi @myxiao ,

exactly, when backwards compatibility cannot be preserved, the old node is to be deprecated, and a new node to be published.
In practice, we realized that deprecating nodes from one day to another (and thereby ending the usual level of maintenance) puts a lot of immediate work on many users. As a result, we want to enable users to phase out old nodes more smoothly. We are still working out the final definition of what “legacy” means, but the rough gist is like:

• The node is backwards compatible
• The node is still supported (though in maintenance mode), but its use is discouraged
• Usually there is a successor/alternative node available that covers the essential part of the nodes functionality (though not all, such that the two nodes are not fully compatible)
• The node is going to be deprecated sooner or later. We do not have a fixed time frame here. Depending on the node(s) this might be ~1 year.

In essence, when building a workflow, you should not use legacy nodes. Except, you really have to use them, because the new/alternative nodes do not support your use case (yet).

If a node is marked as deprecated, the legacy flag should be ignored.

I hope this answers you questions. If you have more questions or ideas how to improve the process, please let me know.

Best regards,
nan