Resumo

  • A exclusão comum no NuGet.org retira o pacote das listas usuais, mas mantém o download e a restauração de uma versão exata.
  • O aviso de descontinuação orienta o usuário; a transferência aprovada de popularidade ajuda o sucessor na busca. Os projetos dos clientes continuam dependendo de uma mudança efetiva.
  • Fechar uma linha de software exige concluir a migração, entregar permissões e preservar conhecimento. Organizar o catálogo resolve apenas parte do trabalho.

A equipe que encerra um produto costuma ter uma data. A equipe do cliente tem outra agenda. Entre as duas cabe um pacote antigo que continua chegando toda vez que alguém reconstrói o projeto.

No NuGet.org, essa convivência faz parte das regras. O fornecedor pode tirar uma biblioteca da exposição comum enquanto o usuário continua buscando a versão que já conhece. A placa foi embora, mas o balcão ainda atende quem chega com o número da peça.

A política oficial mantém download, instalação e restauração de versões retiradas das listas. Uma restauração com versão flutuante também pode escolher uma delas quando for a mais recente que satisfaz as restrições. A replicação do catálogo inclui esses pacotes.Política de exclusão do NuGet

Para quem precisa reconstruir um sistema, isso vale muito. O resultado de ontem não deveria depender de o fornecedor ainda gostar daquela linha de produto hoje. A plataforma protege essa continuidade limitando o poder de apagar o passado por uma operação administrativa comum.

O botão não conhece o orçamento

A referência do comando nuget delete mostra como o efeito depende do destino. No NuGet.org, ele retira o pacote das listas. Numa pasta local, apaga.Documentação do comando

Um relatório que anuncia “exclusão concluída” precisa dizer onde. A cópia interna desapareceu? O pacote saiu da busca? O cliente alterou a dependência? A diretoria pode comemorar qualquer avanço real, mas terá problemas se contabilizar o primeiro como se fosse o último.

A equipe do NuGet mantém procedimentos excepcionais para remover conteúdo nocivo ou que infrinja direitos. O encerramento comercial de uma biblioteca envelhecida é outro assunto. Se toda mudança de estratégia permitisse recolher as peças usadas por terceiros, a promessa de reconstrução teria prazo de validade decidido no departamento de vendas.

A regra desloca a negociação. O fornecedor consegue reduzir a descoberta do produto, mas precisa de outro mecanismo para fazer o cliente sair. Compatibilidade, testes e tempo da equipe compradora entram na conta. Nenhum deles fica mais barato só porque o catálogo parece mais limpo.

O aviso ficou no site

NuGet permite marcar um pacote como descontinuado, informar o motivo e sugerir uma alternativa. Essa marcação funciona separadamente da retirada das listas. Pode-se fazer ambas. Um detalhe reduz o alcance do discurso de despedida: a mensagem personalizada aparece no NuGet.org, e não nos clientes.Descontinuação e transferência de popularidade

Versões compatíveis do Visual Studio exibem informações na tela de pacotes instalados. Um comando dotnet consulta dependências descontinuadas. Para que a informação vire trabalho, alguém precisa chegar a esse ponto do processo. Uma equipe cujo fluxo habitual continua funcionando pode simplesmente seguir a própria fila.

A assistência à migração compra atenção e reduz incerteza prática. Qual alternativa usar? Que comportamento testar? Quem resolve o problema se a troca falhar? Economizar na explicação pode transferir horas para cada cliente e depois trazê-las de volta como chamados repetidos.

O número de avisos enviados mede a disposição do fornecedor para falar. O número de projetos efetivamente alterados mede a mudança que ele precisa obter. São métricas diferentes, com consequências diferentes para a data de encerramento.

Dá para transferir popularidade, não a agenda do cliente

O NuGet aceita pedidos para transferir a pontuação interna de popularidade de um pacote antigo para um sucessor. Isso pode beneficiar a posição do novo pacote na busca. Os contadores reais de downloads permanecem como estão. As referências nos projetos dos usuários também esperam que alguém as altere.

Há revisão e condições. Todos os proprietários precisam ser compartilhados; nome ou função devem mostrar uma relação clara; as versões antigas devem estar marcadas como descontinuadas e apontar para a substituição. O sucessor precisa ter uma versão estável, e a mudança não pode confundir a busca. A pontuação pode ir para até cinco novos pacotes, em partes iguais. Um pacote que já recebe popularidade de outro não pode repassá-la numa cadeia.

A divisão igual merece atenção de quem separa uma biblioteca em módulos. A engenharia pode atribuir funções muito diferentes a cada peça. A área comercial pode apostar quase tudo em uma delas. A distribuição da reputação acumulada, porém, segue a regra do serviço.

Isso cria uma diferença entre possuir um nome e monetizar seu passado. Numa aquisição, acesso às permissões, posição de busca e migração dos usuários precisam aparecer como trabalhos distintos. Chamar tudo de base adquirida de clientes pode colocar no preço de compra uma tarefa que ainda será paga de novo pela equipe de integração.

Quem assina o pacote pode não ter a chave

No NuGet.org, os proprietários controlam permissões e publicação. O campo de autoria nos metadados não decide quem tem esses poderes. A transferência pode ser feita adicionando um novo proprietário, que aceita o convite, e depois retirando o anterior. Convite pendente significa entrega pendente.Publicação e gestão de proprietários

Essa distinção aparece em reorganizações aparentemente simples. A documentação muda de equipe, mas a próxima atualização ainda depende de alguém que já foi deslocado. Ou a permissão passa adiante e ninguém sabe por que uma exceção de compatibilidade foi mantida. A chave e a memória precisam chegar ao destino.

Para calcular a exposição de um fornecedor específico, faltam nas regras gerais as versões usadas por seus clientes, os compromissos de suporte e as migrações já concluídas. São essas informações que permitem escolher quem ajudar, quanto tempo manter a equipe e quando reduzir o esforço.

O passado do software cabe num arquivo. A saída desse passado exige coordenação. O NuGet conserva a peça; a empresa ainda precisa organizar quem vai parar de depender dela.