[FreeBSD-Announce] FreeBSD 11.0 end-of-life

[Franco Fichtner]

Hi Garrett,

> On 10. Dec 2017, at 6:55 AM, Garrett Wollman <wollman at bimajority.org> wrote:
> 
> <<On Sat, 9 Dec 2017 08:05:51 +0100, Franco Fichtner <franco at lastsummer.de> said:
> 
>> Hi,
>>> On 8. Dec 2017, at 8:25 PM, FreeBSD Security Officer <security-officer at freebsd.org> wrote:
>>> 
>>> +--------------------------------------------------+-----------------------+
>>> |releng/11.1|11.1-RELEASE|n/a     |July 26, 2017   |11.2-RELEASE + 3 months|
>>> +--------------------------------------------------+-----------------------+
> 
>> Is there *any* indication when X + 3 is going to be?  Because as a downstream
>> vendor X + 3 months usually translates to X, because there is no time to prepare
>> for any of this, especially when swift adoption is enforced by upstream, e.g.
>> by deprecated packages, quarterly branch and locking users out of the ports tree.
> 
> Yeah, that's been one of my concerns all along with this new
> deprecation schedule.  It takes me about a month to qualify a new
> release, and we have only two windows a year when I can actually
> deploy it (after testing) -- from 12/26 to 12/30, and from the Monday
> after the first Saturday in June until the Friday before the first
> Monday in September.[1] Release schedules in recent years have been
> pretty pessimal for me as it is.  I'll be rolling out 11.1 later this
> month, but if 11.2 were to happen in March I'd be SOL before I could
> even think about upgrading.

That's likely.  The issue description was refined on IRC a bit and basically
goes like this:

If we have to plan upgrades of production systems running FreeBSD 11.1 now
for all of 2018 WRT 11.2 and not missing the EoL deadline -- how would we
plan for it?  We can't, because there is no indication when that is going
to be in the first place.

There are two solutions:

1. Support 11.(x-1) along with 11.x and keep the unpredictable schedule.

2. Set a predictable schedule as soon as 11.x comes out for when 11.(x+1)
is planned, even if that deadline is not met in the end.

I slightly favour the first solution, but it is clear that it will mean work
for an SO.

There is probably a third and fourth action and I would like to see the
bright and steering FreeBSD project members to take a constructive interest
in this matter and not let it go uncommented.


Cheers,
Franco