.. This file is part of Sympathy for Data. .. Copyright (c) 2020 Combine Control Systems AB .. .. Sympathy for Data is free software: you can redistribute it and/or modify .. it under the terms of the GNU General Public License as published by .. the Free Software Foundation, version 3 of the License. .. .. Sympathy for Data is distributed in the hope that it will be useful, .. but WITHOUT ANY WARRANTY; without even the implied warranty of .. MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the .. GNU General Public License for more details. .. .. You should have received a copy of the GNU General Public License .. along with Sympathy for Data. If not, see . .. _migrations: Migrations ---------- If we need to update a node in the standard library your existing copies of that node might need migrating. This is signaled by a colored icon above the node. The color and tooltip of the icon can give you more information about this migration. To perform a migration right-click on the node and select *Refactor* -> *Migrate node*. This can update the configuration and ports of the node and even swap it for a completely different node. In all but a few rare corner cases this should leave the node working just as before. Migration statuses ~~~~~~~~~~~~~~~~~~ A green migration will never change what the node does and is applied automatically when executing the node. Configuring a node with a green migration status will also migrate it to the latest version. A yellow migration has to be triggered manually, either because of technical limitations in the migration system, or because the migration cannot guarantee that it will preserve the nodes behavior. Most of the time though, the node should continue working as before. A red migration status means that the node can not run without being migrated, but the migration can also not be performed without changing the node's behavior. This could for example be the case if a node uses an option that has since been removed completely from the node. The node can still be migrated, but the behavior will have changed and the flow will need to be adapted to the new behavior. These situations should hopefully not be very common. Migrations and overrides ~~~~~~~~~~~~~~~~~~~~~~~~ Extra care has to be taken when migrating a node that is selected in subflow settings. The current overrides for the node will be migrated alongside the node, but any overrides for the node that exist in other syx-files will have to be migrated separately by right-clicking on the relevant subflow and selecting *Refactor* -> *Migrate overrides*.