On Wed, 04 Oct 2023, Santiago Ruano Rincón wrote: > > We could have a single file per release with 3 fields: > > > > * package (or package regexp) > > * supported (true/false), trues implies limited support, false means not > > supported > > * comment (should explain the limitation if supported == true) [...] > I like the above suggestion. Just wondering why don't keep the "latest > version with support" and "Date when support ended or will end" fields > currently found in "ended" files.
It's just an oversight, I forgot about those fields. But to be honest, I'm not sure that the first one is actually useful: what does "latest version with support" mean? Version X might be supported now and might no longer be supported in one year. And how does it mesh with backports? The date one might be more useful indeed, when we decide to follow the upstream support schedule for instance. On the opposite, it might be useful to be able to say that the source package is still supported but only when you use at least version X because we have switched to a backport of a new upstream version compared to the version initially provided (it would be a special case of limited support? or maybe we need to have different types of entries in the file?) (If we make those changes, it's probably also the right time to take care of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765452 with the possibility to exclude some binary packages.) Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hert...@debian.org> ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
signature.asc
Description: PGP signature
