¿Existe una definición estándar de lo que constituye una versión (revisión) de cambio

Question

Actualmente estoy en un infierno burocrático en mi empresa y necesito definir qué constituye los diferentes niveles de cambio de software en nuestros programas de prueba. Tenemos una práctica aproximada que seguimos internamente, pero estoy buscando un estándar (si existe) para hacer referencia en nuestro sistema de Calidad. Reconozco que los sistemas pueden variar mucho entre los desarrolladores, pero en última instancia estoy buscando una guía de "mejores prácticas" para lo que constituye un cambio importante, un cambio menor, etc. Me gustaría hacer referencia a un documento publicado en mi presentación a nuestro sistema de calidad para Propósitos ISO si es posible.

Para aclarar el software desarrollado en mi empresa se utiliza internamente para la automatización de prueba de semiconductores. No estamos vendiendo este código y el control de versiones es realmente solo para el mantenimiento de registros. Estamos utilizando los cambios x.y.z para efectuar el nivel de aprobación y aprobación necesarios para la versión.

Answer 1

Una buena práctica es el uso de 3 números de revisión de nivel:

xyz

x es el principal y es el menor z son correcciones de errores

Lo importante es que dos diferentes programas informáticos las versiones con la misma x deben tener compatibilidad binaria. Una versión de software con una y mayor que otra, pero la misma x puede agregar características, pero no eliminar ninguna. Esto asegura la portabilidad dentro del mismo número principal. Y, por último, z no debería cambiar ningún comportamiento funcional a excepción de las correcciones de errores.

---

Editar:

Estos son algunos enlaces a planes de número de revisión utilizados:

• http://en.wikipedia.org/wiki/Software_versioning
• http://apr.apache.org/versioning.html
• http://www.advogato.org/article/40.html

Answer 2

para verla en lo @lewap dijo, utilice

xyz

donde los cambios de nivel z son casi en su totalidad correcciones de errores que no cambian las interfaces o involucrar a sistemas externos

donde los cambios de nivel y añaden funcionalidades y puede cambie la interfaz UI/API además de corregir errores más serios que pueden involucrar sistemas externos

donde los cambios de nivel x implican algo desde una reescritura/rediseño completos hasta simplemente cambiar las estructuras de la base de datos a bases de datos cambiantes (es decir, de Oracle a SQL Server) - en otras palabras, cualquier cosa que no es una gota en el cambio que requiere un "puerto" o proceso de "conversión"

Answer 3

yo añadiría número de compilación con el formato x.y.z:

x.y.z.construir

x = característica importante cambio cambio
y = característica menor
z = corrección de errores sólo se
acumulación = incrementa cada vez que el código se compila

Incluyendo el número de compilación es crucial para fines internos, donde la gente están tratando de descubrir si un cambio particular está en los binarios que tienen.

Answer 4

Creo que podría diferir si está trabajando en un software interno frente a un software externo (un producto).

Para el software interno, casi nunca será un problema utilizar un esquema definido formalmente. Sin embargo, para un producto, la versión o número de versión es, en la mayoría de los casos, una decisión comercial que no refleja ningún criterio técnico o funcional.

En nuestra empresa, el x.y en un esquema de numeración x.y.z está determinado por los niños y niñas de marketing. La z y el número de compilación interno están determinados por el departamento de R & D y realizan un seguimiento en nuestro sistema de control de revisiones y están relacionados con el sprint en el que se produjo (sprint es el término de Scrum para una iteración).

Además, definir formalmente algún nivel de compatibilidad entre las versiones y las versiones podría hacer que usted se mueva rápidamente o apenas se mueva. Esto podría no reflejar una funcionalidad adicional.

Answer 5

Creo que el mejor enfoque para que usted pueda explicar a sus compañeros de trabajo es mediante ejemplos tomados de paquetes de software bien conocidos y exitosos, y la forma en que abordan los lanzamientos mayores y menores.

Lo primero que diría es que la notación de punto mayor.minor para las versiones es una invención relativamente reciente. Por ejemplo, la mayoría de las versiones de UNIX en realidad tenían nombres (que a veces incluían un número sin sentido) en lugar de números de versión.

Pero suponiendo que quiera usar major.minor, numeración, entonces el número principal indica una versión que es básicamente incompatible con muchas otras versiones anteriores. Considere el cambio de Windows 2.0 a 3.0: la mayoría de las 2.0 aplicaciones simplemente no encajaban con las nuevas ventanas superpuestas en Windows 3.0. Para aplicaciones menos abarcadoras, un cambio radical en los formatos de archivo (por ejemplo) podría ser una razón para un cambio de versión importante: WP & n las aplicaciones gráficas a menudo funcionan de esta manera.

La otra razón para un cambio importante en el número de versión es que el usuario nota una diferencia. Una vez más, esto fue cierto para el cambio de Windows 2.0 a 3.0 y fue responsable del éxito de estos últimos. Si su aplicación se ve muy diferente, eso es un cambio importante.

A para el número de versión menor, esto se utiliza generalmente para indicar un chanhe que en realidad es bastante importante, pero que no será perceptible para el usuario. Por ejemplo, las diferencias internas entre Win 3.0 y Win 3.1 eran realmente bastante importantes, pero la interfaz seguía siendo la misma.

En cuanto al número de la tercera versión, muy pocas personas saben que realmente significa y menos cuidado. Por ejemplo, en mi trabajo diario utilizo el compilador GNU C++ versión 3.4.5 - ¿cómo difiere esto de 3.4.4? ¡No tengo ni idea!

Answer 6

Como dije antes en una respuesta a una pregunta similar: La terminología utilizada no es muy precisa. Hay un artículo que describe las cinco dimensiones relevantes. Las herramientas de administración de datos para el desarrollo de software no tienden a admitir más de tres de manera consistente al mismo tiempo.Si quieres apoyar a los cinco que hay que describir un proces de desarrollo:

• Versión (semántica: modificación)
• Ver (semántica: equivalencia, derivación)
• jerarquía (la semántica: consiste en)
• Estado (semántica: la aprobación, accesibilidad)
• Variant (semántica: las variaciones del producto)

Peter van den Hamer y Kees Lepo eter (1996) Gestión de los datos de diseño: las cinco dimensiones de los marcos CAD, la gestión de la configuración y la gestión de datos del producto, procedimientos del IEEE, vol. 84, No. 1, enero de 1996