Mailing-List: contact dev-help@corinthia.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@corinthia.incubator.apache.org
Received-SPF: softfail (nike.apache.org: transitioning domain of
 dennis.hamilton@acm.org does not designate 216.234.124.50 as permitted
 sender)
Reply-To: <dennis.hamilton@acm.org>
From: "Dennis E. Hamilton" <dennis.hamilton@acm.org>
To: <dev@corinthia.incubator.apache.org>
Subject: Support Policies for Corinthia releases
Date: Tue, 3 Feb 2015 08:06:17 -0800
Organization: NuovoDoc
Message-ID: <002f01d03fcb$58cdaed0$0a690c70$@acm.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AdA/x5jJx9LEl1mhQDCXXBR6H10JPA==
Content-Language: en-us
Received-SPF: softfail (supercp.com: domain of transitioning
 dennis.hamilton@acm.org does not designate 75.165.123.152 as permitted
 sender)

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-s=
oftware-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. =20

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
    orcmid@apache.org
    dennis.hamilton@acm.org    +1-206-779-9430
    https://keybase.io/orcmid  PGP F96E 89FF D456 628A
    X.509 certs used and requested for signed e-mail