I have an update site S which provides Plugins Pa and Pb. Pa contains Node X and Y. Pb contains Node Z.
Now I want to restructure my plugins. I want to provide Pa in a new update site Sa and Pb in an update site Sb.
What happens if somebody has installed Pa and Pb from update site S, but updated versions are only provided in the new update sites Sa and Sb. Is it sufficient to only add the new update sites?
What happen if somebody has installed Pa from Site S and tries to install Pa from Site Sa also?
Could I also put a Node into a different plugin (e.g. Node Y into Plugin Pb) without endangering old workflows?
What happens if somebody has installed Pa and Pb from update site S, but updated versions are only provided in the new update sites Sa and Sb. Is it sufficient to only add the new update sites?
Moving extensions between update sites is not an issue, unless explicitly instructed not to do so, KNIME AP use all configured update sites to fulfill installation requests.
What happen if somebody has installed Pa from Site S and tries to install Pa from Site Sa also?
You can not install the same extension twice, in this case they will be offered an update, if the version provided by Sa is higher than the installed version.
Could I also put a Node into a different plugin (e.g. Node Y into Plugin Pb) without endangering old workflows?
This depends, if you do not change the package of the Nodefactory class, old workflows will work out of the box. You can also deal with new package names by using a NodeFactoryClassMapper, see this example form the Vernalis extension:
What is a bit more complicated, is dealing with the use case of opening an old workflow when you do not have the extensions installed, AP will try to install the extension that originally provided the node. If that extension does not contain the node anymore, users are stuck in a loop. They need to manually install extension, that now provides the node.
Unfortuantely I forgot to mention something from my setting:
The mentioned plugins are actually features. So my intention was to separate feature Fa (aka Pa) and feature Fb (aka Pb) into different update sites. Currently they are on the same update site. (The features have a different maitenance priority)
However both features have a shared code base which is provided by a plugin Pc.
So if I create a new release of feature Fa all plugins necessary for Fa get the version label Va. The plugins for feature Fb would get the version Vb for a new release.
If the user installs feature Fa from update site Sa then the plugin Pc with version Va is installed too.
But if the user tries to install feature Fb from update site Sb plugin Pc cannot be installed with version Vb because the Pc is already installed with version Va.
So I guess a separation of Fa and Fb is not recommended if they share code?
ship Pc only from one update site, let’s say the one for Pa, this update site would be required to be enabled for users that want to install Pb. Make sure Pc is not contained in the feature.xml of Fb (as this will pin the version) but only as a dependency in Pb.
You could mark Pc with singleton=false in the MANIFEST.MF editor this only works if Pc does not declare any extensions or extension points (e.g. it contains nodes). This would allow you to install multiple version of the plugin, but requires you to be careful with the dependency version declarations to make this work correctly.
You could also just keep both features on the same update site, but move them into different categories, if all you want to do is to communicate different maintenance levels.
this only works if Pc does not declare any extensions or extension points (e.g. it contains nodes). This would allow you to install multiple version of the plugin, but requires you to be careful with the dependency version declarations to make this work correctly.