Re: Update strategy and timing

> On May 8, 2026, at 9:37 AM, Renato Botelho <garga@FreeBSD.org> wrote:
> 
> On 08/05/26 12:48, bob prohaska wrote:
>> Is there a preferred strategy to timing updates
>> for self-hosted FreeBSD systems?
>> On the stable branches it's easy; just update when
>> updates are announced and build/install. Once caught
>> up, things can be left alone for days at least..
>> With -current there's essentially no pause in the
>> stream of fresh commits, so git finds a new commit
>> by the time buildworld finishes.
>> Is there some marker or indicator that signals the
>> -current tree is at least nominally consistent and
>> buildable? I'm not asking if it'll work, just whenter
>> it's worth a try.
>> For example, my practice has been to run git pull,
>> then make buildworld. If buildworld succeeds, I'll
>> try another pull. If nothing new shows up then run
>> install and reboot. This works with a stable branch,
>> but with -current there are always fresh commits.
>> I've tried looking at the commits to see if they're
>> relevant to problems I'm seeing, rebuilding if they
>> are and proceeding with install if they seem unrelated.
>> Is this approach at all sound? Is there a better way?
> You can follow the stabilization week mark.  More information at:
> 
> https://wiki.freebsd.org/StabWeeks

	+1 to what garga@ said. Generally following the “post-stab week point” is the best way to handle things if you don’t have the cycles to debug/triage new issues.
	If you have any suggestions for missing tests to make your upgrade experience smoother, please discuss them in a new thread. We can get the proposals entered into Bugzilla and hopefully handled in a timely fashion (if the scenarios you’re requesting are easy enough to implement and make sense to cover in a universal manner).
Cheers,
-Enji