Fmriprep: dockerhub tag "latest" useful?

[jdkent]

Question

If we just started using dockerhub today, would there be value in continuing to have the latest tag?

Opinion

For applications like this, I see latest as a way for changes to sneak into other people's use of fmriprep without their intention; perhaps causing their pipeline to break or change unexpectedly. It may also become a little more difficult to report the version used in subsequent articles published using fmriprep.

Is this concern overblown and/or are there good uses of the latest tag I'm not seeing for this (and similar) projects?

I wanted to get a quick opinion on this for other projects, since one has to actively avoid creating a latest tag.

Thanks!

[effigies]

I would be +1 to drop it, as it does create confusion, and lead to people not knowing that they're using an old version. Are we able to remove the tag altogether from DockerHub? I think leaving an old latest that never updates will be even more confusing.

[mgxd]

we had this same discussion with heudiconv, latest can misrepresent the actual version being used, especially since docker will not refresh unless an explicit docker pull is called.

We experimented with removing the tag altogether and instead recommended users pull direct version tags instead (i.e. heudiconv:0.5.4), but there was enough confusion / push back from the community to warrant bringing it back. What we ended up settling on was similar to this repo's implementation:

• versioned tag of each release
• latest (pointing to the latest release)
• master (current master branch, aka unstable)

Furthermore, we're starting to add an automated version checker to some of our packages to combat this problem of a stale latest. A simple check like this:
https://github.com/neuronets/kwyk/blob/e3f7b8140210da7986b5cc0b56c36dc84143ccdb/kwyk/cli.py#L39-L40
with the option to allow developers to send warnings (and possibly stop running bugged versions down the line)

[emdupre]

We experimented with removing the tag altogether and instead recommended users pull direct version tags instead (i.e. heudiconv:0.5.4), but there was enough confusion / push back from the community to warrant bringing it back.

+1 on this. meica only uses versioned tags, and I've had several comments to the effect of "something is broken" because people very much expect there to be a latest tag. I really like the check-based solution @mgxd outlines above !

[jdkent]

I believe whoever has admin access to the dockerhub repository can delete the tag. Here is an example from another project I am an admin for.

Thinking out loud, to go this route, we would need to change:

• docs/contributing.rst
• .circleci/config.yml: in various places
• docs/installtion.rst

and any place a tag is not specifically mentioned.

Thanks @mgxd, and I like the solution you've proposed, especially for projects that have used latest for a while. I'm also apprehensive about removing latest for fmriprep, but I (and presumably others) use fmriprep as a "model" for making other projects, I like to think about decisions that could be made at the onset before community momentum takes hold.

Thanks @emdupre, good to know there is precedence for only using versioned tags too!

[effigies]

I think we actually have been doing the phone-home version check lately, but it's a bit problematic, because we encourage people not to upgrade unless there's a bug they need fixed, to ensure consistent preprocessing across all subjects.

Given that, it might turn out to be a useful speed bump to not be able to use :latest. To try to cut down on explaining ourselves to angry users, we can try to make a FAQ explaining our reasoning very prominent, and point people to fmriprep-docker, which piggybacks on Python's versioning schemes to choose fully-qualified Docker tags.