Currently, we need to cut a new release with every modification to any of the templates. This is incredibly impractical, and typically leads to a concatenation of issues and problems that only surface when deploying.
In order to force updates of the client only when the client has new bugfixes, features or changes API, we should implement an internal update protocol.
For datalad, this is relatively easy, and plays well with versioning (we can think of updating templateflow to a specific tag).
For the S3 this means moving the skeleton somewhere else, and make sure we store all versions of the skels as well as md5 checksums. Then implement a mechanism to update the internal copy of the skeleton.
Currently, we need to cut a new release with every modification to any of the templates. This is incredibly impractical, and typically leads to a concatenation of issues and problems that only surface when deploying.
In order to force updates of the client only when the client has new bugfixes, features or changes API, we should implement an internal update protocol.
For datalad, this is relatively easy, and plays well with versioning (we can think of updating templateflow to a specific tag).
For the S3 this means moving the skeleton somewhere else, and make sure we store all versions of the skels as well as md5 checksums. Then implement a mechanism to update the internal copy of the skeleton.
WDTY?