An application update is a commit
The chart version is pinned in the repository. So an update shows up in the diff, a rollback is a reverted commit, and "it updated itself" becomes impossible.
Chart versions in the catalogue are pinned. An application with an unpinned version gets the status “disabled” and is not installed by this build.
A property follows from this that is worth stating plainly: an application does not update itself.
Why it matters
“It updated itself” is one of the worst phrases in operations. It means the state of the system changed without a human decision, and the investigation has to start without knowing when the change happened.
Most often it happens through a floating tag. The chart refers to an image by a tag like “latest” or by a major version, the content behind that address changes, and on the next reconciliation cycle a different application arrives.
A pinned version removes that mechanism. Until the version line in the repository changes, the same thing is deployed.
What an update looks like
A version change in the description. A commit. Then ArgoCD brings the cluster to the new state.
That makes an update something to discuss: it is visible in the diff, a reason can be attached to it, and it can be scheduled for a window.
And a rollback is a reverted commit. Not a hunt for the previous chart version, not reconstructing from memory who changed what. The previous state exists as an object.
What it costs
Updates have to be done. Nobody will do them for you, and it is work that accumulates.
A project where versions are pinned and nobody raises them for a year ends up worse off than a project with automatic updates: the version gap has grown so large that the update has become a project of its own.
We consider this trade the right one, but it is a trade, and it should be described honestly. Pinning versions moves the risk from “broke by itself at an unknown moment” to “goes stale if nobody looks after it”. The second is a manageable problem; the first is not.
What helps you not forget
The fact that the set is described in one place and lives in the repository. The list of versions is a file you can read, not cluster state you have to query.
Separately: bundled chart archives in the binary mean that updating the catalogue and updating an application are different events. A new build of the tool brings new versions into the catalogue but does not change what is already deployed. Until you edit the description, nothing happens.
The boundary of responsibility
We are responsible for a pinned version deploying the same way it did at certification. We are not responsible for a new version of an application being compatible with your data: that is a question for the application’s author and for your backups.
Hence the practical rule: before updating an application that holds state, take a verified backup. Verified means restored at least once, not merely existing.