4 ms·

This is one of the reasons I never use the latest version of any docker image, so I don’t repeat my constant struggles with npm packages breaking on minor versi

This is one of the reasons I never use the latest version of any docker image, so I don’t repeat my constant struggles with npm packages breaking on minor version changes Edit: I see they were overwriting current tags.... well that’s even worse

Cthulhu_ 9y ago
Latest should only be used for hackery / development, but please fix it to a stable version before release. Overwriting tags should honestly not be possible, ever. Node / NPM did that (I think) with one of their versions too. Or was it a npm package?
- moondev 9y ago
  Use the hash instead of the label. Labels being mutable is helpful because you if you want the most current, bugfixed version of node 7.. node:7
- derefr 9y ago
  > Overwriting tags should honestly not be possible, ever. How do you propose to withdraw a release if it’s broken/contains secret keys/etc.? Delete the image itself and leave the tag dangling?
  - casperb 9y ago
    If secrets are published, there is no way to ‘unpublish’ them. Consider them burned. But they mean: images can be removed, but you should not be able to publish 2 different images with the same tag. Then you never know which version of those two you got.
    - derefr 9y ago
      “Published” doesn’t always mean “public.” You can publish something to an internal company repo, and still want to remove it in case an unscrupulous coworker ever joins and digs through your history. Also, consider “secrets” in the “Personally Identifiable Information” sense, or the “confidential information shared to you by a third party” sense. If these are published, someone might see them; but the longer they stay published, the more people might see them, so you have an obligation to remove them. Also, re: reusing a tag, what about having already announced a release version number, and tagging the release with it, only to find out the release is broken? It’s kind of problematic to have to bump the version again when the previous version didn’t even go out to anyone. I would propose a slightly more relaxed rule: you shouldn’t be able to erase/overwrite a tag once there exist other tags in the repo with creation or signing timestamps newer than those of the targeted tag. So you can overwrite something you just created, but not something that’s “history.” (An alternative to this would be if tags had nicknames or “object versions”, like in an S3 bucket. If you could have a v1.0.0 “tag” that first pointed to a static v1.0.0+1 ref, and then to a v1.0.0+2 ref, where clients don’t see the static ref tags but can still check them out using some special syntax in combination with the visible tag—and where you can revoke a static ref, but not overwrite it—that’d probably make everyone happy.)
- allover 9y ago
  > Overwriting tags should honestly not be possible, ever. Node / NPM did that (I think) with one of their versions too. Or was it a npm package? npm did away with `publish -f` (which would allow that) 4 years ago [1]. [1] http://blog.npmjs.org/post/77758351673/no-more-npm-publish-f http://blog.npmjs.org/post/77758351673/no-more-npm-publish-f
- AgentME 9y ago
  NPM doesn't allow version numbers to be re-used for a new release. (The old drama you might be thinking of was that NPM used to allow packages to be unpublished, which affected a lot of people when someone unpublished their popular module. NPM no longer allows releases to be unpublished after 24 hours.)

Cthulhu_ 9y ago

Latest should only be used for hackery / development, but please fix it to a stable version before release. Overwriting tags should honestly not be possible, ever. Node / NPM did that (I think) with one of their versions too. Or was it a npm package?

moondev 9y ago
Use the hash instead of the label. Labels being mutable is helpful because you if you want the most current, bugfixed version of node 7.. node:7
derefr 9y ago
> Overwriting tags should honestly not be possible, ever. How do you propose to withdraw a release if it’s broken/contains secret keys/etc.? Delete the image itself and leave the tag dangling?
- casperb 9y ago
  If secrets are published, there is no way to ‘unpublish’ them. Consider them burned. But they mean: images can be removed, but you should not be able to publish 2 different images with the same tag. Then you never know which version of those two you got.
  - derefr 9y ago
    “Published” doesn’t always mean “public.” You can publish something to an internal company repo, and still want to remove it in case an unscrupulous coworker ever joins and digs through your history. Also, consider “secrets” in the “Personally Identifiable Information” sense, or the “confidential information shared to you by a third party” sense. If these are published, someone might see them; but the longer they stay published, the more people might see them, so you have an obligation to remove them. Also, re: reusing a tag, what about having already announced a release version number, and tagging the release with it, only to find out the release is broken? It’s kind of problematic to have to bump the version again when the previous version didn’t even go out to anyone. I would propose a slightly more relaxed rule: you shouldn’t be able to erase/overwrite a tag once there exist other tags in the repo with creation or signing timestamps newer than those of the targeted tag. So you can overwrite something you just created, but not something that’s “history.” (An alternative to this would be if tags had nicknames or “object versions”, like in an S3 bucket. If you could have a v1.0.0 “tag” that first pointed to a static v1.0.0+1 ref, and then to a v1.0.0+2 ref, where clients don’t see the static ref tags but can still check them out using some special syntax in combination with the visible tag—and where you can revoke a static ref, but not overwrite it—that’d probably make everyone happy.)
allover 9y ago
> Overwriting tags should honestly not be possible, ever. Node / NPM did that (I think) with one of their versions too. Or was it a npm package? npm did away with `publish -f` (which would allow that) 4 years ago [1]. [1] http://blog.npmjs.org/post/77758351673/no-more-npm-publish-f http://blog.npmjs.org/post/77758351673/no-more-npm-publish-f
AgentME 9y ago
NPM doesn't allow version numbers to be re-used for a new release. (The old drama you might be thinking of was that NPM used to allow packages to be unpublished, which affected a lot of people when someone unpublished their popular module. NPM no longer allows releases to be unpublished after 24 hours.)