3 ms·
If Docker's heavily screwed-up tag system becomes locked into a standard, I may as well slit my wrists now.
by vacri 11y ago
If Docker's heavily screwed-up tag system becomes locked into a standard, I may as well slit my wrists now.
- colordrops 11y agoI agree that the tagging system needs some work. I'm curious as to what you think is wrong with it. Could you share your thoughts?
- vacri 11y agoEverything gets shoehorned into the one tag. Originating repo, image name, version. So next time you pull "x/y:latest", the current holder of that tag loses everything. You see an image in the list with nothing listed - no repo and no image name, when it should just lose the 'latest' tag. If I have multiple images on a machine, I now can't tell which are the old images from a particular repo (well... I can guess by image size), and that's not great if I want to roll back. There is no reason for an image to automatically lose a tag describing where it came from. It also means you have to tag twice using the full tag if you want build numbers: this build is "x/y:latest" and "x/y:v1.2.3", when you could just do "latest" and "v1.2.3". Similarly, when you pull an image, it should pull all tags associated with that layer, so you pull 'latest' and it also brings the tag 'v1.2.3'. This seemed to be the case with the docker v1.5, but it seems inconsistent in 1.6. I haven't had time to nail down that suspicion, though. There are other bits that could do with polish (like being able to do multiple tags at once, rather than push afresh for each one), but the main problem is the single tag field. Given the amount of metadata they already store for an image, this seems a strange behaviour to suffer.