Serguey Asael Shinder: A pinned version needs its end-of-life date written next to it
Linux 7.2.15 came out on 1 November with a note from Greg Kroah-Hartman that it is the last 7.2 release and that users should move to 7.3. He also said it ended a bit sooner than normal, because keeping it would have meant eight stable branches alive at once. (https://lwn.net/Articles/1104629)
Nothing about that announcement breaks anything. That is the point I want to make. A team that pinned 7.2 on a build server or an appliance image will keep building and booting exactly as before. The only change is that the next fix will not arrive, and nothing in the build will say so.
I have written before that a pinned version must hear when it is withdrawn. End of life is the quieter cousin of that: the version is not pulled, it is simply abandoned, and abandonment produces no event at all. The dependency is still on the mirror, the checksum still matches, the tests still pass.
So I now put the end-of-life date next to every pin I control, in the same file: the Dockerfile line, the toolchain file, the version in the build script. A comment is enough to start with. Better is a check in CI that fails when today is past the date, because a comment is read by whoever remembers to read it and a failing check is read every time.
Two details make this worth doing properly. First, the date is not always known in advance. A long-term branch publishes one; a regular stable branch, as this one showed, can end earlier than people assumed. When the date is unknown, write down where it will be announced and who is watching it. Second, the check should fail before the date, not after: a month of warning turns an emergency upgrade into a planned one.
None of this is specific to kernels. A JDK build, a base image, a framework minor line all have the same property: they keep working after support ends. A pin without its end-of-life date is a decision that silently expires.