A build that is going to be used should name exactly what it was built against. Pinning is writing the version down where the build reads it, so the same command tomorrow gives the same artifact rather than whatever is newest.
About 1 min of reading
Read a lock.
The lock
Before you run it, say out loud what it will print. Then open the answer.
Read the first example one line at a time. A line that prints shows what appears on screen; the rest set things up quietly.
The lock file belongs in the repository, not in the build machine. A lock that is not committed is a build that cannot be reproduced by anyone else, which is the whole point of pinning.
A change to a lock file is a diff to read. That diff is where an unintended major bump shows up, and it is the review that stops a silent breakage reaching a release.
A dependency manifest with exact versions is a lock. It is committed, and a build that reads it is reproducible months later, which a manifest of ranges is not.
The runtime version matters as much as the library version. Recording both is what makes a reproduction of a bug a claim someone else can check.
A lock does not move on its own. An update is a command that changes it and a diff that shows what changed, which is the review that catches a breaking bump.
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.