"During that period" refers to the 30-day period. During that time, the images are accessible. After the 30-day period, they will still be pull-able, but not able to be updated.
So, any public image where the maintainer doesn't jump through hoops gets frozen in time, unable to be updated, and starts accumulating CVEs? This sounds worse than deleting the image.
Any smart FOSS maintainer will find alternate hosting...
Can't believe how soon this announcement came after the redhat "we're killing centos support now, best of luck". It's pretty clear how this industry reacts to major support changes with no heads up.
This is an important implication that needs to be brought up in the FAQ explicitly.
In other words, the public repos are being archived. If I was a maintainer responsible for providing up-to-date and secure images, then I think it would indeed by my duty to delete them, if I am no longer able to update them.
> If you don’t upgrade to a paid subscription, Docker will retain your organization data for 30 days, after which it will be subject to deletion. During that time, you will maintain access to any images in your public repositories, though rate limitations will apply.
Specifically (emphasis mine):
> During that time, you will maintain access to any images in your public repositories
So, the logical conclusion, which literally everyone else on HN had, was that after that time you will lose access to images in your public repositories; access meaning "we can get to the image" in this context, because that's what people f-n care about.
Not to mention the other part, about how Docker will still have images available for pull that can't be changed, for which there is no way to "forward" user pulls elsewhere if the developer chose to not pay the fee; so in affect you're capturing their user base with old software and almost no way to know that.
"DevRel" at Docker failed this week. Just own up to it, take the hit, and don't be evasive. Evasiveness is shady and no one trusts that bullshit.
Nah, it's this guy sitting in here trying to tell us how we're supposed to think, that it wasn't their fault we were stupid, that's the issue I have. I don't give a flying FUCK about Docker as a company; whether they live or die matters less to me than when I'll have to pee next.
No, you were not "stupid", and no one is claiming that!! In fact, Docker has gone out of their way to publicly apologize for saying something that was so inherently confusing that it led people--including myself, btw, and I don't even like or use Docker--to believe something they did not mean (that public image would be deleted). If they had written an article saying "we're sorry you're so dumb" I'd get your vitriol, but they are actively apologizing for their poor communication and trying to fall on their sword for causing a misunderstanding... what more do you want?!
Demanding human treatment in all circumstances constitutes a healthy outlook on life. Letting organizations get away with shady tactics should never be tolerated in any society. It may not change anything but it's still important for society to speak out against bad policies and bad decisions
Keeping them read only is literally the worst solution. Old images that can't be updated and accrue security flaws, all while uninformed users see address still work and assume nothing needs to be changed.
Your corporation picked literally worst way to do it.
>> Your corporation picked literally worst way to do it.
I disagree. The worst way would be to make a blanket decision for all projects on their behalf.
This way they let the project maintainer decide.
For projects that don't get updated, it's better to leave them where they are.
For projects that are changing the maintainers can choose to delete (or move to a paid / OSS plan).
Choice is good, and giving that choice to maintainers is good.
The final act if goodness (and I'm not clear yet) is whether maintainers will be able to delete an image at some point in the future. Like say a year from now. Possibly by creating a paid account, and "reclaiming" that image.
Personally I agree that your advice to delete them may be the best option for most maintainers who have decided to leave. And they currently have the ability to do that.
Hence my assertion that your statement is incorrect.
You didn't address the issue of security. The problem with leaving it up to the projects is that projects won't necessarily respond, and we don't want the foundations of the next Mantis 26M rps botnet to get its start from PULL insecure:latest.
What did this mean in that case? That the images will continue to exist but the maintainers cannot update them? They'll just become orphaned?