Updated Design: Version Control (markdown)

Design:-Version-Control.md

@@ -9,15 +9,6 @@ It is desirable to have a single artefact (or logical set of artefacts) that can
 
 The priority is version control of flows/credentials - and is the main focus of this work. The *Added Nodes* scenarios are for a future piece of work.
 
-### Added Nodes
-
-Currently, a user simply npm installs nodes in their user directory to add them to the runtime - or uses the admin api to do so. There is no requirement to maintain a `package.json` file. But it is that file that needs to be version controlled in order to have a restorable system.
-
-This raises some questions:
-
- - should we try to create/maintain a package.json file under the user directory - in much the same way that `npm install --save` does.
- - should we do this via the Storage API so alternative (non-filesystem) based solutions can make use of it
-
 ### Deployed Flows
 
 Use cases include:
@@ -91,3 +82,14 @@ There are two parts additions to the UI:
   - each list entry provides the ability to load that version into the editor. If the workspace is currently dirty, doing so will first prompt to confirm changes will be lost. 
 
 ![](images/vc-deploy-menu/vc-deploy-menu.png)
+
+### Added Nodes
+
+Target: future
+
+Currently, a user simply npm installs nodes in their user directory to add them to the runtime - or uses the admin api to do so. There is no requirement to maintain a `package.json` file. But it is that file that needs to be version controlled in order to have a restorable system.
+
+This raises some questions:
+
+ - should we try to create/maintain a package.json file under the user directory - in much the same way that `npm install --save` does.
+ - should we do this via the Storage API so alternative (non-filesystem) based solutions can make use of it