Changes to the FreeBSD Support Model

Will this change in the support policy allow point -RELEASE's to be made more often, thereby more closely tracking changes on that particular branch of stable? Rather than some of the 8+ months that have happened in the past between point releases?

Thank you for clarifying cperciva!

FWIW, this was how long we typically supported releases anyway -- FreeBSD 6.x was supported from November 2005 until November 2010, FreeBSD 7.x was supported from February 2008 until February 2013, FreeBSD 8.x from November 2009 until June 2015, and FreeBSD 9.x from January 2012 until December 2016 -- but we heard from users that a promise was far more useful than a vague "well, typically...".

Whenever a new point release is made (e.g. 11.1) all previous point releases will be deprecated after 3 months (e.g. 11.0)

This is really the most important change, and addresses a problem we've had for a while: When a point release comes out, we have no idea how long it will be until the next point release. For both users and the security team, knowing the end of the support period relative to the arrival of the next point release (i.e., the overlap time) turns out to be more important than knowing the end of the support period relative to the start of the support period.

@cperciva answered those questions for me in a much more pleasant way than you did.

That being said, the reason I am confused is because it doesn't really change anything. Releases were already for the most part supported for 5 years, and new releases were already cut once every two years (look at 9.0-RELEASE and 10.0-RELEASE).

Yes. Although this is probably better characterized as "two balls actively being thrown and one ball on its way down", since we've never done new point releases in the last year of a major branch (and I doubt that will change).

No dedicated timeline for minor releases. Could still be 13 months between 11.1 and 11.2.

Correct. We decided many years ago that FreeBSD worked better if we did releases "when they were ready" rather than working to a calendar. I'm sure OpenBSD's schedule works well for OpenBSD, but our projects are quite different (e.g., OpenBSD development is more centralized in a small number of hands).

Doesn't address question of what actually gets back ported. Will new em updates go into stable?

FreeBSD is a volunteer project. Updates get merged if someone merges them. Aside from policy restrictions, which are not changing (e.g., we won't merge ABI or API-breaking changes, because we insist on supporting third-party software), it's entirely up to people having the time and interest.

If support for a new device can't be merged into older releases because it relies on ABI/API breaking changes, do you want to be told that you won't be able to use your shiny new hardware in a FreeBSD release for the next five years?

Two years is a compromise between "don't try to support too much at once" and "make sure that people don't have to wait too long to access new features".

I started as a FreeBSD developer in the 4.x era. It was somewhat of an anomaly. The SMP work that went into (and delayed) 5-CURRENT was absolutely necessary, but it introduced significant instability and ongoing breakage. That was a strong disincentive to using it as a day-to-day development platform. I needed a stable development and build machine, so it ran 4.x.

Since then as a project we've done increasingly well at keeping -CURRENT in a working state. It is completely feasible for a volunteer developer to run only -CURRENT.

Then, there's Arch which is popular with enthusiasts, and Ubuntu has become sufficiently different from Debian that it requires thinking when switching from one to the other. Gentoo seems to be getting less and less popular, but it's still kicking.

And yes as the parent post said, it's the unexpected differences that are stressful: different init systems, selinux vs apparmour vs nothing, different locations of config files, different whole /etc structures, that sort of things. The distros are diverging fast, and switching from RHEL to Ubuntu nowadays feels like it's a whole new system.

So you went from downstream to upstream and the view was largely the same. Yeah that's expected.

> I think the opening for FreeBSD and everyone else is that with containers and virtualization

FreeBSD has had container based virtualization for 15 years. I know it's the Brittany Spears of the linux dev group ATM, but I doubt it and Docker are as big a thing as it seems now. Container based virtualization is great, but it's not a substitute for a real hypervisor. As more people realize the last fact, the shine will wear off.

I've been admining Debian boxes for more than a decade so I'm aware of the drawbacks of its policies. That's why my desktop tracks unstable. But for a sysadmin, freezing everything for long periods of time makes for an enormous reduction in churn-related administration time. Having nothing but security updates to install until the next version comes out 2+ years later is excellent. For the exceptions, pinning can often solve the problem. And if pinning doesn't work, there's always building from source.

Like I said above, I'm new to FreeBSD so I'm not sure how much churn I'll have to endure, but I'm looking forward to finding out.

I think he meant branches which are supported for an extended duration. The quarterly branches are (currently, and as far as I know this isn't going to change) supported only for the quarter in question.

Is there any chance the quarterly approach may get stretched out to cover a longer time period? Anything would be helpful to give busy sysadmins breathing room.