Understand immutability of packages

Last Update: 3/6/2017

Team Services | TFS 2017

Once you publish a particular version of a package to a feed, that version number is permanently reserved. You cannot upload a newer revision package with that same version number, or delete it and upload a new package at the same version.

In NuGet, trying to publish a package@version to a feed that already contains that package@version returns a "409 conflict" exception.

Package caching requires immutability

Many package clients, including NuGet, keep a local cache of packages on your machine. Once a client has cached a particular package@version, it will return that copy on future install/restore requests. If, on the server, you replace package@version (rev 1) with a new package@version (rev 2), the client is unable to tell the difference. This can lead to indeterminate build results from different machines. For example, a developer's machine and the build agent might have cached different revisions of the package, leading to unexpected build results.

Dealing with broken and incorrect packages

If a package is broken, buggy, or shares unintended content (like secrets), the best response is to prepare a fix and publish it as a new version. Then, depending on the severity of the issue and how widely depended-on the package is, you can unlist or delete the package to make it unavailable for consumption.