-
Notifications
You must be signed in to change notification settings - Fork 170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handling of EOL ROS distros #79
Comments
For any image @tianon and I directly maintain, we drop a version as soon as it is EOL; there are simply too many we maintain to keep them longer than is absolutely necessary. If you want to keep the EOL ROS releases and are willing to continue maintaining the image and ensuring they continue to build, then I don't have any objections. What do you think @tianon? One possible failure that might arise during the EOL period but before the base distro is EOL would be a change to |
Yeah, sounds fine to me, as long as the base image is still supported and
the image still builds successfully.
|
After thinking on what our priorities should be for EOL tags, and I'm beginning rethink my statement:
Perhaps my opinion of what our priorities should be here has shifted: from prolonging the building of EOL images for security updates, to preserving the archive of the legacy image tags. Given that the tags are for the specific repo, the obligations for those tags should primarily belong to the repo they are apart of, not necessarily any other repo or project. So, when a release reaches EOL, and support is no longer provided, so too should this be reflected in the tag. Users who chose to continue with EOL release/tag should acknowledge that no maintenance or security updates will be necessarily provided. So given that tags are not primarily obligated to upstream base images, and that after EOL, no expectations for security should be kept, I think the one remaining priority would be to preserve the archive, and capture the final operating state of the EOL image. @mikaelarguedas makes a good point here #93 (comment)
Plus I would think that any users with extraordinary use cases in relying on EOL releases could just as easily build the EOL dockerfiles themselves. This is perhaps more consistent with previous policy in catering to niche build cercumatices. |
Thanks everyone for the feedback (here and offline). |
As ROS distos enter end of life, there is the question as to how we should maintain their presence on official library/ros repo. As observed, the current practice seems that once a version release under a given tag reaches EOL, the tag is eventually omitted from the build listing for the library, and new images for the tag are no longer pushed to the registry given the release will no longer receive updates.
Such is the case I see for ubuntu, where older images for 10.04 or 12.04 present within the registry and can be pulled by users, though legacy tags are not blatantly advertised on the doc pages, encouraging users to migrate to supported releases, legacy tags are also not deleted from the registry, preserving the archive.
Given that:
My own opinion would be that these tags should be properly archived in library/ros as well. More specifically, I think that once the upstream base image for a tag in library/ros is no longer updated by the docker hub library, only then should we really remove ROS tags from the official build manafest.
This touches another issue; given non LTS ROS releases tags, such as Jade, targeting LTS base images, such as Ubuntu 14.04, be left active in the build manifest for the duration of the base image support?
One may argue:
I think the second point would be mitigated by any such changes breaking the build at the deb install process, given the pinned version numbers embedded in the dockerfile preventing any consecutive pushes from regressing the tags before it is omitted from the build manafest. But perhaps there are some unforeseen runtime variability I am unaware of.
What I think this really comes down to is what state we wish to leave images once they reach EOL. Would we prefer to leave the tagged images at up to date as we can, and drop support with the finality of the EOL of the ROS distro? Or try and generate the operability of tag after it is omitted from the build manafest?
pringing: @mikaelarguedas @tfoote @j-rivero @tianon @yosifkit
The text was updated successfully, but these errors were encountered: