¿Cuánto tiempo esperar antes de eliminar un método obsoleto? [cerrado]

Mantengo una API pública y tengo que desaprobar un método.

¿Existe una regla general sobre cuántos meses / años / versiones antes de la eliminación debo desaprobar un método?

Como mínimo, debe mantener los métodos obsoletos en una versión antes de eliminarlos, lo que parece bastante obvio cuando lo escribo. No creo que haya un tiempo máximo, pero si nunca los eliminas, la desaprobación se vuelve un poco inútil.

Las versiones principales son un buen momento para eliminar métodos obsoletos. Las versiones menores normalmente no deben contener cambios importantes. Como cHao ha señalado en los comentarios, la desaprobación no necesariamente implica que habrá una eliminación final, por lo que si planea eliminar las cosas después de la desaprobación, debe anotar explícitamente eso y proporcionar alguna orientación sobre la línea de tiempo.

Esto depende únicamente de qué tipo de estabilidad le garantice a sus usuarios y cuánto dolor quiera causar a sus usuarios.

Idealmente, su API usa semver para que cualquier cambio importante provoque que se incremente el número de versión principal. En la práctica, es deseable hacer esto casi nunca. Si su API se instala a través de algún administrador de paquetes, es posible que desee crear un nuevo nombre de paquete después de un cambio importante para que una actualización simple no cause conflictos (por ejemplo, myapi2 v2.123.4vs myapi3 v3.2.1). Eso puede ser innecesario si su administrador de paquetes admite dependencias de versiones más estrictas (por ejemplo, una especificación de dependencia como ~v2.120esa no incluye v3.*), pero los diferentes nombres de paquetes tienen la ventaja de que las versiones incompatibles se pueden usar juntas muy fácilmente. Incluso cuando se usa semver, puede ser sensato tener un período de desaprobación.

Semver no siempre es aplicable. Entonces es más importante comunicar una política de estabilidad clara. Por ejemplo:

• Las características experimentales pueden eliminarse sin previo aviso.
• Las funciones se pueden eliminar por razones de seguridad en cualquier momento.
• Otras funciones solo se eliminarán
  • ... después de haber quedado en desuso en una versión lanzada
  • ... donde esa versión tiene al menos tres meses de antigüedad
  • ... y estará marcado por un golpe en la versión principal.

Dichas políticas funcionan particularmente bien cuando tiene lanzamientos regulares para que haya un período claro de desaprobación, por ejemplo, un año.

Además de marcar cualquier parte de la API como obsoleta, debe hacer que la obsolescencia sea ampliamente conocida. Por ejemplo:

• Tenga una sección en su registro de cambios sobre futuras direcciones y desaprobaciones.
• Transmita su intención de desaprobar antes de realizar la desaprobación y escuche a la comunidad para ver si hay objeciones sustanciales.
• Comunique qué beneficios provendrán de estos cambios. Dependiendo de su base de usuarios, los boletines, presentaciones, publicaciones de blog o comunicados de prensa pueden ser medios apropiados. Dando un giro “¡estamos creando una nueva característica increíble! (que requiere que se elimine esta característica antigua ampliamente utilizada) "es un poco menos frustrante que eliminar una característica sin contexto.

En cuanto al período de desaprobación exacto para elegir, primero mire si debe cumplir con los contratos de soporte con sus usuarios. Dichos contratos pueden requerir que mantenga la compatibilidad durante algún período. Si no, considere cualquier impacto aguas abajo. Intente cambiar menos rápidamente que los usuarios intermedios para que puedan pasar por un ciclo de desaprobación propio. Los usuarios intermedios tardarán un tiempo en adaptarse a sus cambios, por lo que nunca debería tener un período de desaprobación de menos de un mes.

Idealmente, querrá esperar hasta que ya nadie use el método obsoleto. Teniendo en cuenta que está utilizando una API pública, es fácil de rastrear, pero puede terminar esperando mucho tiempo.

en 2015, Google tuvo un problema similar con la API stlport en su sistema operativo Android. Lo habían dejado en desuso y querían eliminarlo, pero toneladas de aplicaciones todavía lo usaban. Encontraron una solución inteligente:

Esencialmente, agregaron una suspensión de 8 segundos () durante el arranque de cualquier aplicación que todavía usara la API con un mensaje de registro apropiado para los desarrolladores. Un mes después, lo duplicaron a 16 segundos. luego, otro mes después, pudieron eliminar de forma segura la interfaz API porque no quedaba nadie usándola.

Esta puede ser una forma muy efectiva de hacerlo. El único problema real es si su API es muy antigua y ha utilizado activamente consumidores que ya no son compatibles. Desafortunadamente, es probable que no puedas arreglar a esos consumidores tú mismo, pero en ese momento no puedes hacer mucho más que eliminar el método y romper el consumidor.

El tiempo mínimo para proporcionar métodos obsoletos depende de los ciclos de desarrollo de los programas que utilizan su API. Como cifra aproximada, 1 año debería ser suficiente.

En cuanto al tiempo máximo antes de que tenga que eliminar los métodos obsoletos, argumentaría que no existe tal cosa. No importa cuánto espere, eliminar un método obsoleto siempre romperá algo. Algunos programas que usan su API en desuso no se mantienen de forma activa, y romper la compatibilidad significará el final de la vida útil de dichos programas.

Le sugiero que elimine los métodos obsoletos cuando obtenga algo de la eliminación :

• se detecta un error que afecta específicamente a métodos obsoletos
• está a punto de refactorizar el código y mantener métodos obsoletos requeriría un esfuerzo considerable
• estás optimizando la estructura interna de tu biblioteca, y los métodos obsoletos ya no encajan.

Eliminar los métodos obsoletos solo porque fueron obsoletos durante X meses / años o porque está lanzando una nueva versión equivale a dañar arbitrariamente la compatibilidad sin una buena razón.

Primero debe considerar si desea obsoleto u obsoleto.

En desuso debe usarse para métodos que de alguna manera son dañinos: seguridad, rendimiento, resultados incorrectos. Desea deshacerse de ellos relativamente rápido, no más de 2 versiones principales y desapareció para el 3er. Para problemas suficientemente significativos, en desuso puede ser eliminado en la próxima versión menor.

Obsoleto es para cosas que son menos útiles por alguna razón, por ejemplo, devuelve menos información o no funciona tan bien, no incluye tantas opciones, etc. Estos pueden permanecer indefinidamente, pero como mínimo deberían estar presentes en la próxima versión principal.

La respuesta depende del tipo de servicio que esté brindando a sus clientes.

En un extremo del extremo, hay errores en Windows.h de la era Win 3.1 que se propagó durante dos décadas porque Microsoft creía firmemente en la compatibilidad con versiones anteriores.

En el otro extremo del espectro, muchas aplicaciones web eliminan funciones sin siquiera proporcionar una advertencia de desaprobación.

La cantidad que sus clientes pagan por su software a menudo es importante, al igual que su línea de trabajo. Los investigadores científicos suelen estar más dispuestos a aceptar la despreciación como parte de la marcha del progreso que, por ejemplo, los banqueros o la FAA.

Trabajé para una empresa que desarrolla software para uso interno. Apoyé a muchos grupos a lo largo de los años. Un grupo tenía una mentalidad de "nunca eliminar ninguna característica". Necesitaban la capacidad de volver a los archivos hace 5-10 años y analizarlos en escalas de tiempo demasiado rápido para que los desarrolladores volvieran a poner las características. La actitud de un grupo era "asegurarse de que todas las depreciaciones estén en las notas del parche, por lo que puede encontrarlos más tarde ". En el medio, teníamos un grupo cuya regla era "Las características deben ser obsoletas para al menos 1 versión con una advertencia impresa si se usan antes de eliminarlas". Ese grupo tenía un conjunto de pruebas que cubría las características que necesitaban. Cada vez que lanzamos una nueva versión, ejecutaron rápidamente su conjunto de pruebas para ver si alguna de las desvalorizaciones les daba problemas.

Mantengo una API pública y tengo que desaprobar un método.

¿Por qué necesitas hacer esto? ¿Es porque hay una nueva forma brillante de hacer las cosas, por lo que ahora se desaconseja el método anterior, pero aún funciona bien? ¿O es que el viejo método realmente tiene que desaparecer porque las cosas han cambiado fundamentalmente?

• Si el método anterior no está causando ningún problema real y puede mantenerse, entonces también puede hacerlo. Si no está roto, no lo arregles. ¿Realmente necesitas eliminarlo? Tal vez márquelo como obsoleto e incluya una nota en la documentación de que otro método podría ser más eficiente, o lo que sea, pero probablemente esté bien dejarlo en su lugar.

• Si el método anterior realmente necesita irse, porque le está causando dolores de cabeza de mantenimiento, o porque simplemente ya no tiene sentido debido a otros cambios, entonces monitoree su uso y comunique claramente la depreciación a los clientes. Déles una fecha clara después de la cual se eliminará el método. (Idealmente, no lo elimine de inmediato en esta fecha: espere hasta que nadie lo siga usando antes de eliminarlo realmente. Es posible que deba hacerlo antes, si realmente está causando problemas, pero al menos espere a que el uso deje de funcionar. pequeño.)

• Si el método anterior está causando problemas de seguridad, es posible que deba moverse más rápido que eso, posiblemente incluso eliminarlo sin previo aviso, pero debe documentar este cambio en algún lugar muy visible y también devolver mensajes sensibles a los clientes que intentan utilizar el método anterior.

(Los segundos dos puntos están bien cubiertos en otras respuestas, pero creo que el primero es nuevo).

Para un proyecto público, elimínelo solo si es necesario.

Cuando realiza una eliminación innecesaria de API, le cuesta dinero a las empresas y contratistas de tal manera que ni siquiera puede calcular debido a la costosa rotación.

¿Quiere que las empresas y los programadores independientes dejen de usar su proyecto? Rompe sus cosas suficientes veces cuando no seas esencial y estarás en ese bote en poco tiempo.

deprecation != eventual_removal. Si una API es peligrosa, la eliminas. Si es simplemente viejo, déjelo y documente su reemplazo.