¿La versión principal rápida que choca es una evidencia de un diseño pobre?

16

Comencé un trabajo como programador junior hace unos meses. El sistema en el que estamos trabajando ha estado en producción durante ~ 2 años. No participé en la mendicidad del sistema y el diseño.

Una cosa que he notado es que la versión principal del sistema ya es 11.YZ. Formando mi experiencia trabajando con otros sistemas y bibliotecas, no recuerdo haber visto una versión principal que golpeara el producto tan rápido. Hay productos que han estado durante años en 1.XY, y todavía reciben características y correcciones de errores.

Suponiendo que el control de versiones semántico se usa correctamente, ¿esto indica que el sistema está mal diseñado ya que realiza cambios importantes cada cuatro meses?

versioning semantic-versioning

— usuario367035
fuente

2

Esa pregunta dependerá de si esos grandes cambios importantes traen suficientes beneficios (y ganancias) que justifiquen la alta tasa de cambio.

— rwong

3

Si ese número de versión usa Semver, y si el sistema tiene una biblioteca u otra API de la que dependen otros equipos u organizaciones, entonces este número mayor significa que ha habido problemas para comprometerse con un diseño de API estable y extensible. También significa que comunicar claramente incompatibilidades es altamente valorado, lo cual es algo bueno. Para cualquier otra cosa (como nombres de marketing, programas de aplicación, números que no sean de Semver, ...) el número no tiene sentido y se debe ignorar en gran medida. Pregúntele a sus compañeros de trabajo sobre esto, como parte de usted para conocer mejor el proyecto.

— amon

3

@amon El sistema se usa internamente con clientes móviles públicos que se comunican con el sistema a través de una API tipo REST. El control de versiones es Semver como mencioné y no una versión de marketing.

— user367035

El número no importa, pero sospecharía si el identificador de la versión incluye algún acrónimo lindo, como Windows NT o Windows ME o XP o realmente cualquier cosa de Windows.

— John Wu

1

@JohnWu: la pregunta es específicamente sobre el número, así que sí, el número sí importa. Más precisamente, se trata de la cantidad en el contexto de SemVer, donde el número no sólo hace la materia, pero también tiene un significado precisión especificada.

— Jörg W Mittag

14

Suponiendo que el control de versiones semántico se utiliza correctamente, ¿indica esto que el sistema está mal diseñado ya que realiza cambios importantes cada cuatro meses?

No necesariamente.

Usted mencionó en los comentarios que esta es una API interna. Romper una API es malo, porque rompes el código de todos. Pero para una API interna, "todos" son solo "usted", y usted es perfectamente capaz de coordinar dichos cambios de API consigo mismo, por lo que el dolor que generalmente se asocia con los cambios de API es mucho menos grave.

Además, el promedio podría ser enormemente engañoso: ¿tal vez tuvieron 11 cambios de API de última hora durante los primeros días de desarrollo temprano y se han mantenido estables durante 4 años desde entonces? SemVer le permite realizar cambios importantes sin aumentar el número mayor si el número mayor es 0, pero no lo obliga a hacerlo. ¿Quizás comenzaron a usar SemVer desde el día 0, incluso durante las fases de creación de prototipos / exploración?

— Jörg W Mittag
fuente

55

Esta respuesta parece abordar directamente la pregunta. Algunas de las otras respuestas serían válidas si no fuera por la suposición de OP de versiones semánticas.

— joshp

También es notable que los cambios importantes no siempre son importantes. A veces son realmente bastante pequeños (pero importantes). Por lo tanto, podrían necesitar muy pocos cambios para los usuarios. Además, puede haber un grado bastante grande de cambios importantes dependiendo de cómo se use la API. A veces, un cambio importante no afectará a todos los usuarios, por ejemplo. Además, las correcciones de errores pueden introducir cambios importantes, sin embargo, es ideal solucionarlos lo antes posible. Y si la API es interna, entonces es mucho más fácil manejar estos pequeños cambios importantes.

— Kat

1

Respuesta corta

No

Respuesta larga

"A veces un número es solo un número"

Olvídate de "versiones semánticas", "racionalidad", "lógica" en el mundo loco actual

¿Por qué Chrome engulle los números de versión tan rápido?

los números de "versión" se utilizan como hitos para los puntos de ramificación, no para versiones principales para sorprender al público de la forma en que otros desarrolladores los usan. Y es un flujo de desarrollo continuo, con características listas o no listas, en lugar de un evento ocasional que reúne muchas características nuevas para hacer un gran evento

— Tejón perezoso
fuente

77

El OP ha dicho que están usando versiones semánticas; ¿Por qué lo ignoras?

— Jörg W Mittag

-3

Cuando se utiliza el control de versiones semántico, aún queda la decisión de qué cambios se consideran "mayores" y cuáles son "menores". Hay varias razones para aumentar el número de versión, o para no modificarlo.

Los sistemas con promesas de compatibilidad con versiones anteriores podrían terminar aumentando el número de versión principal con la mayoría de las actualizaciones, solo porque hay una interrupción de compatibilidad con versiones anteriores en algunos casos de esquina más o menos esotéricos. Los mismos sistemas podrían quedarse en 1.xy casi indefinidamente, porque se pone mucho esfuerzo en la compatibilidad con versiones anteriores, tratando de nunca romper ningún sistema dependiente. Ambos enfoques para la numeración de versiones podrían considerarse "conservadores", pero ambos también podrían ser un signo de un profundo problema subyacente.

Otras veces, en realidad tiene un cronograma de lanzamiento (piense en los CD de actualización trimestrales enviados a los clientes) donde tiene sentido cambiar el número de versión principal, de modo que en lugar de "Versión 3.4 / 16 de octubre" simplemente dice "Versión 11.0". Hoy en día, se lanza cada vez más software en intervalos cortos, lo que hace que los cronogramas de lanzamiento sean una razón menor para apegarse a un esquema de versiones específico. He visto esto en grandes sistemas de almacén que permiten que la TI interna solo tenga un día de inactividad por trimestre (generalmente un domingo). Este día es el día de implementación y está marcado con una nueva versión principal cada vez.

Algunos programas tienen dependencias externas que son de suma importancia, ya que el usuario tendrá que actualizar ambos al mismo tiempo. Si tiene un complemento de Word que solo funciona con Word 2010 y otro para Word 2013, es posible que desee sincronizar sus números de versión principales con los de MS-Word. Aquí, los números importantes son muy importantes, porque algunos de sus usuarios estarán "atrasados" en su programa de actualización normal, ya que no se han actualizado a la versión más reciente de Word (o cualquier otra cosa en la que confíe: SAP, Dynamics, etc)

A veces, otros factores externos dictan los números de versión. Si tiene software fiscal, puede haber actualizaciones anuales correspondientes a la ley tributaria (que tiende a entrar en vigencia el 1 de enero). Dichos sistemas tendrán versiones principales que cambian exactamente una vez al año, no porque ese sea el cronograma de actualización, sino porque eso es de otra importancia para el cliente: si hace sus impuestos de 2016, es mejor que tenga un programa que se actualice a la ley de impuestos de 2016.

Al final, los números de versión dependen de tantos factores, a menudo específicos de un dominio, que el número por sí solo no le dice nada sobre el estado de su base de código. Es un enfoque mucho mejor observar cuándo, por qué y cómo ocurren las implementaciones, y con qué facilidad. Si puede implementar una actualización importante para 10.000 clientes y hacer un par de llamadas telefónicas, probablemente esté bien. Si implementa un parche menor para 10 clientes y tiene que trabajar horas extras debido a eso, probablemente algo esté mal.

— Hazzit
fuente

3

"Cuando se usa el control de versiones semántico, aún queda la decisión de qué cambios se consideran" mayores "y cuáles son" menores ". - No, no lo hay; eso se define con precisión en la especificación. "Hay varias razones para aumentar el número de versión, o para no modificarlo". - No, no los hay; hay precisamente una razón para aumentar el número mayor (de lo que trata esta pregunta), y se define con precisión en la especificación.

— Jörg W Mittag

1

@ JörgWMittag O lo estoy leyendo mal, o la especificación dice específicamente cuándo DEBES cambiar los números de versión, pero no dice nada sobre cuándo PUEDES.

— Hazzit

-4

El consenso sobre el significado de los números de versión es de hecho major.minor.revision.buildnumber

Si las principales suben rápidamente, podría ser que el desarrollador tenga todas estas nuevas ideas y trabaje realmente duro.

Sin embargo, en el mundo de los negocios puede haber otras razones para incrementar el número de versión principal. Me gusta

Las ventas han bajado, los clientes / usuarios están esperando el próximo gran lanzamiento antes de actualizar.
El contrato dice que los clientes tienen derecho a actualizaciones menores. El vendedor no puede cobrarles por eso, por lo que se vende una pequeña mejora como una importante actualización del producto.
El competidor X ha estado en el juego un poco más de tiempo, por lo que su número de versión principal es más alto que el tuyo. Esto hace que parezca que te estás quedando atrás, tienes que "ponerte al día".

— Martin Maat
fuente

66

La pregunta está etiquetada con versiones semánticas , el OP menciona las versiones semánticas en la pregunta y ha reafirmado en los comentarios que están utilizando versiones semánticas. La especificación SemVer dice muy claramente cuándo se incrementan las versiones principales. Ninguno de sus "otros motivos" se aplica.

— Jörg W Mittag