The existing upgrade command is pretty limited in what it is able to do. It simply rewrites the stack.json and docker-compose file with newer image tags from a different version manifest. If there is any additional migration (such as config changes) required between versions it will not work.
As an example, when we moved all of the containers to run as a non-root user the FireFly CLI also had to be updated to put config files in a different location which a non-root user could read. This change was backward compatible with older versions of FireFly, but older versions of the CLI would not be able to generate the proper config for newer versions of FireFly. Thus, simply swapping the image tag would not work to move from 1.2.x -> 1.3.x because of permissions changes.
This PR sets some guardrails on the upgrade command to allow it to apply patch releases only (which should not contain these types of changes), and does not allow downgrades.
The existing upgrade command is pretty limited in what it is able to do. It simply rewrites the stack.json and docker-compose file with newer image tags from a different version manifest. If there is any additional migration (such as config changes) required between versions it will not work.
As an example, when we moved all of the containers to run as a non-root user the FireFly CLI also had to be updated to put config files in a different location which a non-root user could read. This change was backward compatible with older versions of FireFly, but older versions of the CLI would not be able to generate the proper config for newer versions of FireFly. Thus, simply swapping the image tag would not work to move from 1.2.x -> 1.3.x because of permissions changes.
This PR sets some guardrails on the upgrade command to allow it to apply patch releases only (which should not contain these types of changes), and does not allow downgrades.