corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: Support Policies for Corinthia releases
Date Tue, 03 Feb 2015 16:21:20 GMT
On Tuesday, February 3, 2015, Dennis E. Hamilton <>

> 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.

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

just my opinion.
jan i

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

Sent from My iPad, sorry for any misspellings.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message