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
