Add additonal requierements and recommendations about upgrades and rollbacks

To improve the general idea include recommendations regarding rollbacks
to build a more secure and robust solution. Also add a section to introduce
the requirement to handle settings during upgrades and rolbabacks.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>

content/designs/system-updates-and-rollback.md

@@ -148,6 +148,14 @@ be customizable. For instance, some products may chose to only roll back the
 base OS and keep applications untouched, some other products may choose to roll
 applications back as well.
 
+Apertis recommends rollbacks to be allowed only after a system upgrade and before
+confirming that the new version works as expected. Enabling rollbacks in general
+could be a potential security issue, since a rollback could be used to install
+a previous release with vulnerabilities. By taking this approach it also
+simplifies how applications have to deal with base OS rollbacks, since
+applications should only upgrade their configuration accordingly when the new
+version is confirmed and there is no possible rollback.
+
 ### Reset to clean state
 
 The user must be able to restore his device to a clean state, destroying
@@ -158,6 +166,13 @@ all user data and all device-specific system configuration.
 An interface must be provided by the updates and rollback mechanism to allow
 HMI to query the current update status, and trigger updates and rollback.
 
+### Handling settings and data
+
+System upgrades should keep both settings and data safe and intact to
+as this process should be as transparent as possible to the end user. As described in [preferences and persistence]( {{< ref preferences-and-persistence.md >}} ),
+since settings have a default value which can changed on upgraded the solution
+is not straightforward.
+
 ## Existing system update mechanisms
 
 ### Debian tools