undefined | Better HN

0 pointsterom3y ago0 comments

If you are deleting the organizational data and effectively archiving [1] all the images, keeping only the option for public images to be pulled but not updated... then how will affected maintainers be able to delete their now out of date public images after the 30 day cut-off? You will have to retain enough of the organization data to allow that to happen.

Keeping the public images available in an archived state is okay for specific image references, but questionable for specific image tags and somewhat irresponsible for the `latest` tag. A `latest` tag that cannot be updated is ... worse than no `latest` tag.

Responsible maintainers that are unable to apply for open-source status or otherwise sponsor their usage of organization public repos should be advised to delete their public repos.

Responsible users of public images on Docker Hub need to have a way to determine which images will be affected, and which will continue to be maintained. Archiving the public repos gives an extended grace period, but users will still need to be prepared to notice if they end up using a now unmaintained, archived repo and migrate to alternative image sources.

[1] https://news.ycombinator.com/item?id=35188691

0 comments

pmoriarty3y ago

"somewhat irresponsible for the `latest` tag. A `latest` tag that cannot be updated is ... worse than no `latest` tag"

What's irresponsible is relying on a "latest" tag for updates.

TheDong3y ago

The irresponsible thing is making it so the tag exists, but the organization behind it cannot update it.

Let's take for example the "jenkins/jenkins:latest" image.

Jenkins is notorious for having security updates, so in 2 years, if the latest tag is still there and frozen, it will be an attractive nuisance, causing people to download insecure software...

That's what the parent comment is trying to say. It's irresponsible to leave the image that implies it's "up to date and secure" because it's "latest", but is really insecure, and the organization owning it cannot change anything about that without paying $$. It's basically holding users of the image hostage.

francislavoie3y ago

You missed his point. He's saying "latest is an anti-pattern". Which is correct. Everyone should be pinning to specific versions or semver to avoid being accidentally upgraded to a release with breaking changes.

Yes, obviously making existing tags immutable is bad. Nobody is disputing that.

1 more reply

paranoidrobot3y ago

It's not* just `latest` tags, it will also affect any other image tag.

If you've been referencing org/image:tag where tag=major-minor, and gets updated when there's a patch, then that's going to stop getting updated.

Without either the tag being deleted (and thus your pulls failing), or going out to find updates on that container - you may not notice that it's fallen out of date and the image/tag is no longer being updated.

With the entire organisation being removed from Dockerhub, it sounds like there's not even going to be a way for people to say "We've moved off Dockerhub, our images/source/etc is now over here".

You'll just have to search and hope you can find where it's moved to.

nunez3y ago

is it?

sometimes I want a container running the latest version of something. maybe i'm integration testing my stuff against that release to make sure stuff still works. or maybe I'm hoping a bug was fixed and will version pin later.

i agree that production software should version-pin all the things, but latest still has a place.

j / k navigate · click thread line to collapse