How would this work? I'm guessing that the container would keep the same options as it was started with (entrypoint, command, port mappings, networks, volumes, environment variables, etc.) but be restarted using a new base image.
The devil is in the details, though. What do you do with files that were created in the container but aren't part of the a volume? A simple solution would be to throw them all away and start fresh, but then the "upgrade" command would only be able to work correctly for a subset of containers where throwing away previous files would be OK. If that were the case, I think "replace" would be a better command name than "upgrade" since you're effectively, if not literally, replacing the container.
Any other approach where you keep the files in from the old container files would lead to all sorts of corner cases or odd behavior. What if the upgraded image has moved where files are stored? What if the upgraded image's configuration is incompatible with the previous image's version?
I feel that users understand well that files outside of volumes are basically temp files. Those who don't end up learning it the hard way at some point. This is why I think that pulling the image, stopping the container and starting a new one with the same parameters would be the right thing to do.
It is very easy to do manually unless the command to start the container is lost, at that point a tool like the one being discussed becomes handy.
