Handling of EOL ROS distros

[ruffsl]

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:

• Indigo and later have nested tag that are not replicable without the official library, and
• These distros where at one time supported by the official library

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:

• Removing a tag prematurely before the final push of its base image would forever leave the tag out of sync with upstream, thus lacking any final security updates or system patches.
• Alternatively, halting the pushing of the tag at a known state could help prevent regressions between the duration of the EOL of the tag, and final base image push.

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

[yosifkit]

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 packages.ros.org/ros/ubuntu that changes the signing key. If you do decide to keep supporting old versions, you'll probably want to watch the ros Official Image builds for any failures that might need a fix.

[tianon]

Yeah, sounds fine to me, as long as the base image is still supported and the image still builds successfully.

[ruffsl]

After thinking on what our priorities should be for EOL tags, and I'm beginning rethink my statement:

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.

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)

as soon as a distro is EOL or a ROS distro is EOL we should stop updating and rebuilding the docker images. This way we can provide the closest image to what was last built on the buildfarm. Users can always update their system afterwards but we won't have to support any breakage that this could cause

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.

[mikaelarguedas]

Thanks everyone for the feedback (here and offline).
I believed we reached consensus and implemented the option "Stop building images for EOL versions of our projects (ROS and Gazebo) regardless of the EOL status of the base images" so I'm going to close this.