I was just pointed to this interesting post about depth of support for released artifacts: <http://www.tedunangst.com/flak/post/long-term-support-considered-harmful>.
That article links to an interesting problem about the GHOST exploit against a vulnerability in glibc, <https://blog.hboeck.de/archives/864-What-the-GHOST-tells-us-about-free-software-vulnerability-management.html>. It strikes me that it is important that any support policy be explicit. That is, when does/will support for a version end, what exceptions might there be, and for how long. It is also important to have an effective way for downstream users to know when the support life is/will end for a given release or related binaries, and to be able to know when a new release provides critical updates that may impact their usage. Some creativity may be needed for accomplishing effective notifications. - Dennis THINKING OUT LOUD There can be two factors in this. Releases that repair serious defects, such as crashers, data corruption, and security vulnerabilities my involve fixes to Corinthia source codes. They may involve dependencies in convenience binaries where the defect in the dependency extends into Corinthia. Even though the replacement of a dependency version may be a minor change in the Corinthia code base, it may be appropriate to do a release and make new convenience binaries for built libraries and executables that the dependency is bolted into that code. This support-life business should perhaps be a factor in deciding exactly what convenience binaries the project is willing to provide and support. I think we need to be clear about what level of release versions counts with respect to the aging policy. Going from m.n.p to m.n.(p+1) probably should not (assuming a "semantic versioning" practice). Going from m.n.* to m.(n+1).* probably should count as a version step in terms of any support assurance. If the policy is to extend support two back, it would be at that m.* level. When there is a change at the m level, One might support the previous two releases for a longer time because of the m+1 changes being so significant, especially if there is a change in system requirements. -- Dennis E. Hamilton [email protected] [email protected] +1-206-779-9430 https://keybase.io/orcmid PGP F96E 89FF D456 628A X.509 certs used and requested for signed e-mail
