Limits of NuGet floating version ranges for zero‑downtime migration

Goal: achieve zero‑downtime migration of a small .NET application while keeping dependencies up to date.

Constraint: the build must remain deterministic across environments, yet teams often prefer floating ranges like 1.0.* to receive automatic patch updates without editing the project file.

Uncertainty: it is unclear whether relying on such floating ranges introduces non‑deterministic restores that could jeopardize the migration guarantee, or whether a lock‑file‑only approach sacrifices the benefit of automatic updates.

Does using a floating version range lead to non‑deterministic builds that affect zero‑downtime guarantees? Should lock files be committed and used exclusively, or can they coexist with floating ranges? Which version‑range strategy provides predictable upgrades without risking breaking changes during migration?