Current set up of the GAMBLR does not allow for proper tracking and version-centric use of the bundled data.
The user can only see changes through git history, but to actually use one of the earlier versions a separate environment and package installation are required. In addition, with continues development and data addition, some data like aSHM coordinates are bound to change (add new regions, rename existing, curate coordinates etc.). This will not allow reproducible scripts as there is no backward compatibility.
This needs to be resolved by allowing user to use a specific version version of the bundled data on a session-based or project-based basis without need for package installation.
One way this can be addressed is by using a designated and separate data package, which will have incremental version increase as new data is released. At the same time, GAMBLR needs a way to handle this and recognise which version of the bundled data user is requesting at the time of first package load.
Current set up of the GAMBLR does not allow for proper tracking and version-centric use of the bundled data. The user can only see changes through git history, but to actually use one of the earlier versions a separate environment and package installation are required. In addition, with continues development and data addition, some data like aSHM coordinates are bound to change (add new regions, rename existing, curate coordinates etc.). This will not allow reproducible scripts as there is no backward compatibility.
This needs to be resolved by allowing user to use a specific version version of the bundled data on a session-based or project-based basis without need for package installation.
One way this can be addressed is by using a designated and separate data package, which will have incremental version increase as new data is released. At the same time, GAMBLR needs a way to handle this and recognise which version of the bundled data user is requesting at the time of first package load.