please merge master back into development upon release(s)

[yarikoptic]

which should be a fast-forward since I believe master keeps merging specific development upon release.

Just my 1c, ATM

$> git describe --tags upstream/development
v1.0.20200427-97-g0587941

so hard to tell exactly "where we are in development" in the history (makes trickier to mint comparable to releases "snapshot" version to produce some "development" package), also development might miss some "released" change.

[neurolabusc]

@ningfei notes: Actually, merging master branch back to development branch or not will NOT affect the tag for development branch: if you never commit and push directly to master branch but always merge new things from development branch to master branch. The development branch will automatically get the correct tag after you set the tag in the master branch, since the tag is bound to a specific commit and they both have that commit already. Merging back to the development branch will help, if you happen to commit something to master branch directly, thus the commits are not in the development branch. Anyway, it's safe to merge back I think, belt and braces.

I am not familiar enough with git tags to know how to remove the offending tag. If you can tell me how to do it, I will do so.

$git describe --tags development
v1.0.20190410-192-g05a5d23
$ git push origin development :refs/tags/v1.0.20190410           
remote: warning: Deleting a non-existent ref.
To https://github.com/rordenlab/dcm2niix.git
 - [deleted]         v1.0.20190410
$ git push origin development :refs/tags/v1.0.20190410-192-g05a5d23
remote: warning: Deleting a non-existent ref.

I try to generate stable releases every 6 months, and solicit feedback from users with large datasets and do a time consuming validation that goes beyond the tests completed for every commit. The development branch is always started from the end of the last stable release, so it should not miss any released change. However, it is not as extensively tested and includes more experimental features (e.g. recent changes for huge Philips PAR/REC datasets) that might break things.

One issue is that my validation datasets (like dcm_qa, dcm_qa_enh, dcm_qa_ge, etc) all include my implicit biases for how dcm2niix is used. Further, my center only has Siemens equipment, so it is unclear to me if dcm2niix supports some nascent work-in-progress sequences from other manufacturers.

Someone like you is ideally positioned to develop a heudiconv validation suite that could test commits to detect issue prior to stable releases. Doing this at the level of heudiconv could allow you to validate not only dcm2niix, but also test alternatives like nibabel.

[yarikoptic]

I am not familiar enough with git tags to know how to remove the offending tag.

git tag -D offending # if desired to remove locally
git push remote :offending # to remove on remote

[yarikoptic]

Re downstream testing: would be great. We started to do similar testing for datalad extensions and git annex itself.