corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject Support Policies for Corinthia releases
Date Tue, 03 Feb 2015 16:06:17 GMT
I was just pointed to this interesting post about depth of support for released artifacts:

That article links to an interesting problem about the GHOST exploit against a vulnerability
in glibc,

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


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    +1-206-779-9430  PGP F96E 89FF D456 628A
    X.509 certs used and requested for signed e-mail

View raw message