Summary

  • Ordinary deletion on NuGet.org unlists a package while leaving its exact version available for download, installation and restore.
  • Deprecation can point users towards a replacement; approved popularity transfer can help that replacement in search. Customer projects still require an actual migration.
  • A product retirement needs separate budgets for moving users, handing over publication rights and preserving knowledge. Cleaning the catalogue settles only the catalogue.

The cheapest part of retiring a software product is taking down the sign. A product manager can do that before lunch. Persuading customers to remove the old component from their working applications may occupy rather more of the calendar.

NuGet.org makes the difference unusually clear. A publisher can remove a package from ordinary discovery while a customer continues to request a particular version. The shop window has changed. The parts counter still recognises the order.

Under NuGet's deletion policy, an unlisted version remains available for exact-version downloads, installation and restore. Even a floating-version restore can select it when it is the latest version satisfying the constraints. Catalogue replication also includes unlisted packages.NuGet deletion policy

That continuity has commercial value. Rebuilding yesterday's project is a much less useful promise if yesterday's components disappear whenever their publisher reorganises its catalogue. NuGet protects the customer's ability to recover those dependencies by limiting what an ordinary publisher action can erase.

The same arrangement leaves a retiring supplier with work. It can discourage fresh discovery. It cannot use that single administrative act to complete the migration of existing users.

Ask where the deletion happened

The command's name is impressively decisive. Its jurisdiction is more modest. The official reference says nuget delete unlists when the source is NuGet.org, but deletes when the source is a local folder.NuGet command reference

A manager reading “deletion complete” should therefore ask for the location. An internal copy may have gone. A search result may have disappeared. A customer's project may have changed its dependency. Those are three different accomplishments, and only the last establishes that this particular project has moved.

NuGet's team retains exceptional removal routes for harmful or infringing material. Ordinary commercial retirement follows another process. A supplier's desire to stop maintaining an unfashionable line is not a general permission to dispose of components on which other organisations have come to rely.

The practical consequence is a change in bargaining power. A catalogue decision can be made inside the supplier's meeting room. A migration requires time in somebody else's engineering schedule. Compatibility work, tests and a convincing destination enter the price of the exit.

The farewell speech may stay on the website

NuGet provides a deprecation notice with a reason and, optionally, a recommended replacement package or version. Deprecation and unlisting are independent; a publisher can use both. There is a useful limit on the reach of the announcement, however: the custom message appears on NuGet.org rather than in clients.NuGet deprecation and popularity-transfer rules

Supported Visual Studio versions display deprecation information in the installed-packages view. A dotnet command can query deprecated dependencies. Information still needs to meet a working habit: somebody opens that view or runs the query. A customer whose usual restore succeeds may continue with its own priorities.

This is where migration assistance earns its budget. Someone must choose the successor, understand the change, reserve testing time and decide who handles a failure. A supplier can economise on explanation and distribute the resulting research bill among its customers. Some of that saving may then return as repetitive support enquiries.

Counting announcements flatters the publisher. Counting successfully changed projects reveals whether the intended result has arrived. A communication task can be complete long before a product line is ready to close.

Search reputation comes with an inheritance rule

NuGet also accepts requests to transfer an old package's internal popularity score to a successor, helping the new package's search ranking. Actual download counts remain unchanged. References in customer projects stay where their owners left them.

The transfer requires review. All owners must be shared, the names or functions must have a clear relationship, old versions must be deprecated with the replacement specified, and the new package needs a stable version. The change must not confuse search. One old package can send popularity to up to five new packages, divided equally. A package already receiving popularity from another cannot pass it onwards through a transfer chain.

Equal division is an intriguing constraint for a company splitting a library into modules. Engineering may draw the boundaries by function. Sales may expect most future business from one module. The service still allocates the inherited search weight by its own rule.

That makes discoverability a conditional asset. It has value, but its transfer needs an accepted operation and it does not carry users across with it. An acquisition team should price the package name, management rights, search position and completed customer migrations separately. Otherwise it may buy an unfinished integration task under the more attractive label of an acquired customer base.

The author on the label may not hold the keys

NuGet.org assigns management and publication powers to package owners. Author metadata inside the package does not determine those rights. A handover can add a new owner, wait for that person to accept the invitation and then remove the previous owner. A pending invitation leaves the handover pending.Publishing and package ownership

Imagine a reorganisation in which the documentation has reached the new team but the next release still requires someone who has moved to another job. Or the permissions have arrived, while nobody remembers why an awkward compatibility exception exists. Authority to publish and knowledge of how to move the remaining customers need different parts of the handover.

A particular supplier's exposure requires its actual customer dependency versions, support commitments and completed migration records; the general policies contain none of those totals. Those records give retirement planning something concrete to price: whom to help, which knowledge to retain and when the remaining effort can shrink.

An archive preserves the old output. Leaving that output behind is another piece of work. NuGet keeps the component available; the supplier still has to organise the departure of people who depend on it.