On Tuesday, February 3, 2015, Dennis E. Hamilton <[email protected]> wrote:
> 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. Well for this project we might choose only to release source and avoid all these problems, at least for a long time until DocFormat is stable. Some of us might outside the project provide convenience binaries. So in total I do not really see downstream users or binary releases before DocFormat is stabilized. At the moment we do not have resources to support that. just my opinion. rgds jan i > > - 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] <javascript:;> > [email protected] <javascript:;> +1-206-779-9430 > https://keybase.io/orcmid PGP F96E 89FF D456 628A > X.509 certs used and requested for signed e-mail > > > -- Sent from My iPad, sorry for any misspellings.
