---
title: A guide to risky changes to the standard library and toolchain
---

Please take special care when working on **risky changes**.
As a reminder:

A change is risky if it can cause **failures that are hard to diagnose** (for example, changes to
the runtime, GC, compiler, linker, TLS, other low-level component, or **complex changes that
need soak time under production workloads**), or if it **requires many CLs that are hard to
revert** (for example, large CLs or stacks of CLs).

If you plan on working on a change that may be risky, please do the following:
1. Unless the entire change is absolutely trivial to revert, protect the new code paths with a
   boolean flag, prefixed with `go125`, that can be used to quickly toggle back to the old
   implementation.
   It can be a simple bool constant, for example, `const go125UseEvenBetterLinker = true`.
   Such flags **must be findable** by a simple grep for the string `go125`.
   That way we can find them without missing any, and they can be cleaned up when we get to the
   Go 1.26 cycle.
2. Consider how you would answer the following questions for your change:
   * How risky is the change you're planning to make?
   * How will you know if it is working as intended?
   * How much production testing does it need for you to be confident it is working as intended?
   * When should the keep/revert decision be made?
3. Create a tracking issue in the Go 1.25 milestone with a release-blocker label.
   This issue will be used to track progress on the feature and make the final decision for Go 1.25.