Resumen

  • NuGet.org permite retirar un paquete de las listas habituales conservando la descarga y restauración de su versión exacta.
  • El aviso de obsolescencia orienta al usuario y la transferencia aprobada de popularidad ayuda al sucesor en las búsquedas. Ninguna cambia por sí sola los proyectos de los clientes.
  • Cerrar una línea de software exige distinguir la limpieza del catálogo, la entrega de permisos y la migración terminada. Cada una tiene su propia factura.

En una adquisición de software, el nombre de una biblioteca puede caber en una línea del contrato. Sus usuarios, en cambio, no caben en una mudanza tan pequeña. Hay que convencerlos, ayudarles a probar el sustituto y esperar a que encuentren un hueco en su calendario.

NuGet ofrece una buena manera de observar esa distancia. El propietario puede retirar el paquete de la exposición habitual y anunciar un sucesor. Mientras tanto, un cliente que solicita la versión concreta puede seguir recuperándola. El producto ha salido del escaparate; su historia todavía trabaja.

La política de NuGet.org conserva las versiones retiradas para descarga, instalación y restauración. Incluso una restauración con versión flotante puede seleccionar una de ellas si es la más reciente que satisface las condiciones. La réplica del catálogo también las incluye.Política de eliminación de NuGet

Para el cliente, esto protege algo muy poco vistoso y muy valioso: reconstruir un proyecto con los componentes que esperaba encontrar. Para el proveedor, impide utilizar la limpieza ordinaria del catálogo como si fuera una retirada de todas las piezas ya incorporadas a proyectos ajenos.

Una palabra, dos poderes

La documentación de nuget delete hace una distinción que merece llegar a los informes de dirección. Contra NuGet.org, el comando retira de las listas. Contra una carpeta local, elimina.Referencia oficial del comando

Por eso, «ya está borrado» necesita un complemento de lugar. Puede haberse borrado una copia interna, reducido la visibilidad pública o cambiado la dependencia en el proyecto del cliente. Son avances diferentes. Solo el último acredita que ese proyecto se ha movido.

El equipo de NuGet conserva vías excepcionales para retirar contenido perjudicial o infractor. La gestión comercial de una biblioteca envejecida discurre por otro carril. Si cualquier cambio de estrategia empresarial pudiera borrar los componentes antiguos, la promesa de reconstrucción dependería del humor del vendedor.

La plataforma asigna así derechos distintos: el editor controla parte de la presentación, el usuario conserva acceso a versiones concretas y el equipo del servicio administra las excepciones. La retirada comercial se negocia dentro de ese reparto.

La despedida puede quedarse en la web

La función de obsolescencia permite explicar un motivo y recomendar un paquete o una versión de reemplazo. Es independiente de la retirada de las listas. Se pueden usar ambas. Hay, sin embargo, una frontera importante para quien redacta el gran comunicado de despedida: el mensaje personalizado se muestra en NuGet.org, no en los clientes.Reglas de obsolescencia y popularidad

Las versiones compatibles de Visual Studio muestran información de obsolescencia en la vista de paquetes instalados. Un comando de dotnet permite consultar las dependencias afectadas. La información necesita encontrarse con una rutina de trabajo. El equipo que sigue restaurando con éxito puede estar ocupado con su propia lista de prioridades.

El proveedor debe entonces comprar, con claridad y asistencia, una parte de la atención del cliente. Elegir el reemplazo, resolver incompatibilidades y ejecutar pruebas consume horas. Ahorrar en instrucciones puede multiplicar las búsquedas de los usuarios y las consultas al soporte. El coste cambia de mesa antes de volver a la cuenta del vendedor.

Una campaña de avisos tiene una métrica fácil: mensajes enviados. Una transición tiene otra más incómoda: dependencias que han cambiado y funcionan. La segunda permite cerrar un producto; la primera permite cerrar una tarea de comunicación.

La reputación se traslada con condiciones

NuGet admite solicitudes para pasar la puntuación interna de popularidad de un paquete antiguo a un sucesor. Eso puede mejorar la posición del nuevo en las búsquedas. Los contadores reales de descargas no se modifican y los proyectos de los usuarios conservan sus referencias hasta que alguien las cambie.

La operación requiere revisión. Todos los propietarios deben ser compartidos; la relación de nombre o función debe ser clara; las versiones antiguas han de figurar como obsoletas con un reemplazo, y el nuevo paquete necesita una versión estable. Tampoco debe crear confusión en las búsquedas. Se puede repartir hacia un máximo de cinco paquetes, por partes iguales. Un receptor previo no puede convertirse en eslabón de otra transferencia.

Ese reparto puede chocar con el plan comercial. Una empresa divide una biblioteca en varios módulos porque cumplen funciones diferentes. El módulo destinado a generar más negocio no recibe automáticamente una porción mayor del pasado. El servicio distribuye la popularidad con su regla, no con el presupuesto de ventas del propietario.

La posición en un buscador es, por tanto, un activo condicionado. Tiene valor, pero requiere una operación aceptada y no trae consigo la adopción. Un comprador debe separar lo que recibe: nombre, permisos, capacidad de ser descubierto y trabajo pendiente con usuarios. Fundirlo todo en «base de clientes adquirida» puede convertir una tarea futura en un activo ya cobrado.

El autor de la etiqueta puede no tener las llaves

NuGet.org atribuye los permisos de gestión a los propietarios del paquete. Los nombres que aparecen como autores en sus metadatos no determinan esos permisos. Para una entrega de control se añade al nuevo propietario, este acepta la invitación y después puede retirarse al anterior. Una invitación pendiente sigue siendo una entrega pendiente.Publicación y gestión de propietarios

Imaginemos una reorganización: la documentación llega al nuevo equipo, pero la capacidad de publicar permanece con una persona que ya tiene otra función. La siguiente corrección tendrá que recorrer el organigrama hacia atrás. Si las llaves sí se entregaron pero nadie conservó el conocimiento de compatibilidad, la migración volverá a atascarse en otra puerta.

Para valorar un caso concreto hacen falta las versiones realmente utilizadas, los compromisos de soporte y las migraciones terminadas. Las reglas generales no aportan esas cifras. Con ellas se puede decidir dónde ayudar y qué conocimientos conservar, en vez de elegir una fecha de cierre porque queda bien en la presentación.

El catálogo puede estar impecable y la retirada comercial, a medio hacer. NuGet hace visible una verdad poco cómoda para las compras y las ventas de software: el pasado se guarda en un archivo; salir de él requiere personas.