Condividi tramite

Deprecare i pacchetti

  • Articolo

È possibile deprecare un pacchetto se non si mantiene più un pacchetto o se si vuole incoraggiare i consumer del pacchetto a passare a un altro pacchetto.

La deprecazione del pacchetto è diversa dall'elenco del pacchetto, come illustrato di seguito:

  • L'elenco di un pacchetto impedisce l'individuazione perché è nascosta nei risultati della ricerca.
  • Deprecare un pacchetto consente ai consumer esistenti del pacchetto di scoprire se sono installati o usati nei progetti. Consente inoltre di conoscere il motivo della deprecazione e di un pacchetto consigliato alternativo come specificato dall'utente (l'autore del pacchetto). Deprecare un pacchetto non include l'elenco del pacchetto.

In qualità di editore, è possibile scegliere di annullare l'elenco e deprecare i pacchetti.

Flusso di lavoro deprecazione

  1. Per deprecare un pacchetto, passare a Gestisci pacchetti e selezionare Deprecation:

    Go to deprecate package option

  2. Selezionare la versione da deprecare. Se si vuole deprecare tutte le versioni, scegliere Seleziona tutte le versioni .

    Select package versions to deprecate

  3. Scegliere un motivo per la deprecazione. Se il pacchetto non è più gestito, scegliere l'opzione Legacy . Se la versione specifica ha un bug critico, scegliere l'opzione con bug critici . Per qualsiasi altro motivo, selezionare Altro. È sempre possibile specificare un pacchetto consigliato alternativo (e versione) e un messaggio personalizzato ai proprietari.

    Select reasons alternate package recommendation and custom message

Nota

Il messaggio personalizzato viene visualizzato solo in nuget.org ma non dai client. Attualmente, i client come dotnet.exe e il NuGet Gestione pacchetti non mostrano il messaggio personalizzato.

Esperienza client per i pacchetti deprecati

Dopo che un pacchetto è stato deprecato, i relativi consumer ricevono una notifica nei modi seguenti (a seconda del client usato).

Visual Studio

Disponibile a partire da Visual Studio 2019 versione 16.3

Visual Studio avvisa l'utilizzo di un pacchetto deprecato nella Installed scheda. Verrà visualizzato un avviso per il pacchetto e le relative informazioni di deprecazione ( incluso il motivo per cui è stato deprecato e il pacchetto alternativo da usare, se presente).

Deprecated packages on Visual Studio installed tab of package manager

dotnet.exe

Disponibile a partire da .NET SDK 3.0

Se si usa dotnet.exe, è possibile eseguire il comando dotnet list package --deprecated nella soluzione o nella cartella del progetto per ottenere un elenco di pacchetti deprecati insieme alle informazioni sulla deprecazione:

> dotnet list package --deprecated

The following sources were used:
   https://api.nuget.org/v3/index.json

Project `My.Test.Project` has the following deprecated packages
   [netcoreapp3.0]:
   Top-level Package      Resolved   Reason(s)   Alternative
   > My.Sample.Lib        6.0.0      Legacy      My.Awesome.Package

Trasferire popolarità a un pacchetto più recente

Gli autori di pacchetti che hanno deprecato un pacchetto legacy possono scegliere di trasferire la sua "popolarità" a un pacchetto più recente per aumentare la classificazione di ricerca del pacchetto più recente. In questo modo, i clienti individuano il pacchetto più recente anziché il pacchetto deprecato.

Ad esempio, si supponga di avere due pacchetti:

  • Il pacchetto legacy deprecato, Contoso.Legacy con 3 milioni di download
  • Il pacchetto più recente, Contoso.Latest con 5 download

NuGet.org preferisce risultati di ricerca con download/popolarità più elevati. Dato che la query di ricerca "Contoso", il pacchetto Contoso.Legacy deprecato probabilmente classifica al di sopra del pacchetto Contoso.Latest più recente nei risultati della ricerca.

Per risolvere questo problema, posso applicare per trasferire la popolarità del pacchetto legacy deprecato al mio pacchetto più recente. Ciò causerebbe Contoso.Latest una classificazione superiore nei risultati della ricerca, mentre Contoso.Legacy sarebbe inferiore. Solo i punteggi di popolarità interni per i pacchetti sono interessati, il numero di download effettivo per ogni pacchetto non sarà interessato.

Nota

I trasferimenti di popolarità possono rendere notevolmente più difficile per i consumer trovare il pacchetto legacy.

Vedere la tabella seguente per ottenere un'idea concreta del modo in cui un trasferimento di popolarità può influire sulle classificazioni di ricerca per la query "Contoso":

Classificazione di ricerca Prima del trasferimento di popolarità Dopo il trasferimento di popolarità
1 Contoso.Legacy, download 3M Contoso.Latest, 5 download
2 Contoso.Scanner, download 2M Contoso.Scanner, download 2M
3 Download di Contoso.Core, 1.5M Download di Contoso.Core, 1.5M
4 Contoso.UI, download di 1M Contoso.UI, download di 1M
... ... ...
20 Contoso.Latest, 5 download Contoso.Legacy, download 3M

Processo di trasferimento di popolarità dell'applicazione

  1. Esaminare i requisiti di trasferimento di popolarità.
  2. Posta elettronica account@nuget.org con il pacchetto deprecato il cui popolarità deve essere trasferita e, l'elenco di pacchetti stabili che devono ricevere il trasferimento di popolarità.

Dopo l'invio dell'applicazione, verrà notificata l'accettazione o il rifiuto dell'applicazione (con i criteri che hanno causato il rifiuto). Potrebbe essere necessario porre altre domande di identificazione per verificare l'identità del proprietario.

Requisiti di trasferimento di popolarità

  • I pacchetti legacy e i nuovi pacchetti devono condividere tutti i proprietari.
  • I nuovi pacchetti devono essere chiaramente correlati ai pacchetti legacy nella denominazione e nella funzione (ad esempio un'evoluzione o una nuova generazione).
  • Tutte le versioni dei pacchetti legacy devono essere deprecate e puntare ai nuovi pacchetti che ricevono il trasferimento.
  • Il trasferimento di popolarità non deve causare confusione per gli utenti NuGet o peggiorare l'esperienza di ricerca NuGet.
  • I nuovi pacchetti devono avere una versione stabile.
  • Il pacchetto legacy non deve ricevere trasferimenti di popolarità da un altro pacchetto deprecato.

Scenari di trasferimento di popolarità avanzati

Consolidamento dei pacchetti

Posso trasferire la popolarità di più pacchetti deprecati a favore di un singolo pacchetto. Ad esempio, si supponga di avere 3 pacchetti:

  • Primo pacchetto legacy deprecato, Contoso.Legacy1
  • Il secondo pacchetto legacy deprecato, Contoso.Legacy2
  • Nuovo pacchetto consolidato, Contoso.Latest

Dopo aver deprecato Contoso.Legacy1 e Contoso.Legacy2, posso applicare per trasferire la loro popolarità a Contoso.Latest.

Suddivisioni pacchetti

La popolarità di un pacchetto deprecato può essere trasferita a e divisa tra, fino a 5 pacchetti più recenti. Ciò è utile se la funzionalità di un pacchetto deprecato è stata suddivisa tra più nuovi pacchetti. Ad esempio, si supponga di avere 3 pacchetti:

  • Pacchetto legacy deprecato, Contoso.Legacy
  • Primo nuovo pacchetto, Contoso.Web
  • Il secondo nuovo pacchetto, Contoso.Cloud

Contoso.Legacy include funzionalità Web e cloud, ma ho deciso di separare tale funzionalità in pacchetti diversi per la prossima generazione. Dopo aver deprecato Contoso.Legacy, posso applicare per trasferire la sua popolarità a entrambi Contoso.Web e Contoso.Cloud.

Avviso

La popolarità trasferita verrà divisa in modo uniforme tra tutti i nuovi pacchetti. Di conseguenza, è consigliabile trasferire la popolarità del pacchetto deprecato al minor numero possibile di pacchetti.

Catene di trasferimento di popolarità

Un pacchetto deprecato non può trasferire la sua popolarità se sta già ricevendo popolarità da un altro pacchetto deprecato. Ad esempio, si supponga di avere 3 pacchetti:

  • Pacchetto legacy deprecato, Contoso.First
  • Pacchetto legacy deprecato, Contoso.Second
  • Nuovo pacchetto, Contoso.Latest

Se Contoso.First trasferisce la sua popolarità a Contoso.Second, , Contoso.Second non può trasferire la sua popolarità in Contoso.Latest. È invece consigliabile trasferire la popolarità di entrambi Contoso.First e Contoso.Second in Contoso.Latest, in base allo scenario di consolidamento dei pacchetti .