Upcoming Releases Schedule...

[Robert Watson]

On Sat, 20 Sep 2008, Simon L. Nielsen wrote:

> - The more branches are supported, the more versions of both third
>  party code and FreeBSD code need to be supported and the more likely
>  it is that the software differs meaning that we need to adopt the
>  fix to the branch.  The real painful case for this was
>  FreeBSD-SA-07:01.jail which AFAIR needed 6 different patches.  This
>  is one of the largest time cost with support many branches as this
>  is by no means a linear cost.  The older a branch is, the more
>  likely it is that the code is much different than newer FreeBSD
>  versions.
>
>  This also the reason secteam was very happy when we could
>  discontinue FreeBSD 4 support as it was significantly different from
>  FreeBSD 5+.  In that respect supporting FreeBSD 5 in the end was
>  much cheaper than supporting FreeBSD 4 in the end.  Of course this
>  is less likely to be a problem in the future like it was with
>  FreeBSD 4, but still - FreeBSD 5 and FreeBSD 8 are rather different
>  and would not be fun to support both.

Let me give an example from a slightly older branch here as well: we 
de-supported FreeBSD 3.x for "local" security vulnerabilities because we hit 
the libncurses security vulnerability.  The only real option to pick up the 
fix was to adopt new version of libncurses, and that radically changed the 
libcurses API (part of the fix).  This, in turn, cascaded into other 
applications, such as top, vi, etc, which all use ncurses, so the net effect 
would have been not just a significant API change, but also modifications to 
countless system utilities.  Such a change might not even be appropriate for a 
minor branch, let alone a security branch where we try to ensure minimalist 
fixes to avoid security patches leading to other potential regressions.

Robert N M Watson
Computer Laboratory
University of Cambridge