Re: Change to FreeBSD release scheduling etc.

On 7/14/24 05:18, Peter wrote:
> In short, it takes me about 3 months to catch the surprizes[*] and fix
> (or find out how to cope with) the concerning issues, regressions et
> al. that come along with a new release. Up to now that would then give
> another 9 months during which the systems can be operated in a
> plan-of-record fashion, until the next release starts the hassle
> again.

While I see your point, we're hoping that having roughly 2x as many minor
releases will result in at least a 2x reduction in the number of surprises
per minor release -- because not only is less code changing between minor
releases, but also committers feeling less pressure to hit a deadline may
result in code being better tested and less surprise-prone when it lands
in a minor release.

> Thinking about what could be done for remedy, what comes to my mind
> most easily is, simply support two most recent releases, so people
> get the option to skip each other upgrade. That doesn't look like much
> work, basically just backporting occasional security fixes.
> So much as a spontaneous suggestion.

Extending the minor-release support period might be possible, but that
would depend on portmgr and secteam and I can't speak for them.  One issue
which would certainly come up is kernel module packages -- our packages
are built for each stable branch on the oldest currently supported release,
which means that e.g. new features in 14.1 can't be used until 14.0 is EoL;
this is a problem particularly for graphics drivers.

-- 
Colin Percival
FreeBSD Release Engineering Lead & EC2 platform maintainer
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid