Este intento de responder a mi propia pregunta tiene el propósito de estimular respuestas o correcciones de otros en caso de que me falte algo.
El método para estimar depende de cómo se versionen las dependencias. Si no hay forma de que una dependencia anuncie que ha introducido un cambio incompatible con versiones anteriores (en adelante, BIC), la única forma en que un usuario lo sabría es encontrarse con un problema o notarlo leyendo lo que ha cambiado.
No hay un mundo perfecto donde todo siga los mismos esquemas de versiones estrictos. Un BIC puede indicarse incrementando un número de versión principal (en el caso de semver, excepto que la versión principal es cero) o un cambio en una etiqueta personalizada para sistemas más idiosincrásicos. Es posible que otros ni siquiera anuncien BIC en absoluto.
- Cómo definir la integración continua
- ¿Qué es un buen proyecto de fin de año que se trata de Software Quality Assurance?
- ¿Qué tecnología es mejor en el desarrollo de software?
- ¿La programación autodidacta cuenta como una experiencia en ingeniería de software?
- ¿Qué es mejor, trabajar como ingeniero de mesa de ayuda en una gran empresa de TI o trabajar como ingeniero DevOps en una pequeña empresa de TI?
No importa cuál sea el caso, un cambio incompatible con versiones anteriores es un evento independiente clave. Tener una forma de estimarlo para un proyecto determinado significa saber cómo detectar esos eventos para cada dependencia, por lo que es mejor que espere que todo esté versionado de la misma manera (los paquetes NPM son buenos en ese sentido).
Una vez que sepa cómo detectar BIC, entonces viene la cuestión de la frecuencia. Los proyectos altamente activos parecen más propensos a introducir BIC en la superficie, y podría contar el número de BIC introducidos en un mes, trimestre, año, etc.
Pero dado que la probabilidad de BIC para un intervalo dado puede cambiar, una distribución de Poisson no sería muy útil. Aquí es donde llegamos a los factores que complican: Encontrar el riesgo de que ocurran BIC requiere calcular la probabilidad de un evento futuro con datos pasados, pero la probabilidad de que ocurran BIC en un proyecto varía. Los desarrolladores toman descansos, abandonan proyectos o regresan con renovado vigor. Además de eso, los desarrolladores que trabajan en plataformas marcadas como estables no están dispuestos a introducir demasiados BIC seguidos, para que sus usuarios no protesten. La única forma aparente que veo para estimar la probabilidad de que ocurran BIC para un proyecto es monitorear cada proyecto utilizando un medio sensible al contexto y medir los BIC a lo largo del tiempo. Usando los datos de tendencia de esto bajo las restricciones de OP, nos gustaría saber la probabilidad de que al menos un BIC ocurra de una manera que rompa el código de un dependiente (El período de tiempo futuro no se dice, pero podría ser seguro asumir que es el intervalo de tiempo más pequeño en el que la probabilidad de introducir un BIC tiende a cambiar).
Desafortunadamente, aquí es donde mi conocimiento sobre el tema se agota. La vista de pájaro tiene una respuesta, pero los detalles son inciertos en el peor de los casos y contextuales en el mejor.
EDITAR: Ideas interesantes que obtengo después de hablar con compañeros de trabajo.
- Si le importa asignar la culpa, automatice la ejecución de las propias pruebas de una dependencia contra sí mismo, excepto asegúrese de que las pruebas existan un cambio detrás del código fuente. Si las pruebas fallan, pero luego tienen éxito cuando sincroniza las pruebas con el código fuente, es posible que haya encontrado un BIC (o simplemente una corrección de error).
- El otro enfoque es evitar el cuidado de los proveedores individuales y escribir pruebas que expliquen sus expectativas de terceros. Automatice las pruebas de todo el espacio de su proveedor utilizando una fachada o capa reglamentada. El fracaso de estas pruebas indica un BIC. Cuanto más a menudo fallan, más probable es que su proyecto sea un castillo de naipes. Use esto como fuente de conocimiento para estimar cuánta deuda tecnológica o caos pueden tolerar sus desarrolladores.
EDITAR # 2: Abordó el significado de “romper”