> On May 8, 2026, at 9:37 AM, Renato Botelho <[email protected]> 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
signature.asc
Description: Message signed with OpenPGP
