Backbone: Seguir SemVer

Gracias, pero seguir estrictamente el control de versiones "semántico" no funcionaría muy bien para Backbone. Dado que el proyecto es casi toda la superficie, y muy pocas partes internas, casi cualquier cambio dado (parche, solicitud de extracción) en Backbone rompe la compatibilidad con versiones anteriores de alguna manera ... incluso si solo para las personas que confían en un comportamiento previamente indefinido.

Si seguimos estrictamente el control de versiones "semántico", probablemente ya sea Backbone.js 43.0.0 , lo que no ayuda a nadie a evaluar el progreso real del proyecto.

Entonces, como me gusta bromear, no el versionado "semántico", el _ versionado romántico_.

Dado un número de versión MAJOR.MINOR.PATCH, incremente:

Versión PRINCIPAL cuando realiza una nueva versión importante, o actualiza y / o estabiliza significativamente la API.
Versión MENOR cuando agrega características nuevas menores.
PARCHE la versión cuando realice pequeños cambios, que probablemente pasarán desapercibidos para la mayoría.

Esto permite a la gente, inmediatamente después de enterarse de un nuevo lanzamiento, tener una idea aproximada de su alcance. En cuanto a la compatibilidad con versiones anteriores, lo ideal es que _todas_ versiones, incluso las más importantes, sean compatibles con versiones anteriores. Y cuando no sea posible, debido a que una API está cambiando, debe hacerse de una manera que no sea demasiado difícil de actualizar.

Pero evitar cualquier cambio en la API y esperar a que esté lista una versión "PRINCIPAL" sería un gran impedimento para progresar. Y la alternativa de incrementar con frecuencia el número de versión PRINCIPAL es increíblemente inútil.

Honestamente, preferiría un esquema más simple que solo usara números de versión BIG.SMALL , como hacen la mayoría de las aplicaciones de escritorio ... pero me preocuparía que rompa los administradores de paquetes y otras herramientas.

¿Cuál es el problema de estar en Backbone 43.0.0?

• Enviado desde Chrome 32.0.1700

+1 para spadgos @ pregunta. Los números de versión son arbitrarios. Por alguna razón, tenemos aplicaciones web ágiles que intentan mantenerse dentro de los mismos rangos que los sistemas operativos. Muchas aplicaciones se asustan por pasar de 10 ... pero la mayoría de los proyectos que está modelando (Windows, Linux, etc.) tienen ciclos de desarrollo de 1 año / varios años antes del lanzamiento, por lo que 1.x -> 2.x es un gran problema. Un proyecto ágil se mueve muy rápido, incrementar rápidamente también tiene sentido.

También estoy en desacuerdo con el razonamiento detrás de esto.

Marionette está en v1.2.3 en este momento, y está haciendo lo mejor para seguir un control de versiones semántico estricto. Hasta ahora, no hemos tenido ningún problema a pesar de que también somos "toda la superficie". Hemos agregado nuevas funciones. Hemos corregido errores. Pero la v1.0 sigue siendo compatible con la v1.2.3. Hemos aplazado los tickets para una versión v2 cuando son API o cambios de comportamiento esperados.

Los lanzamientos importantes con cambios importantes no tienen que suceder todas las semanas cuando se acepta una solicitud de extracción. Estos pueden (y deben) agruparse en una versión principal que abarque el valor suficiente para una versión grande con un aumento de la versión principal.

Tal como está, romper la compatibilidad en una versión v1.1 causa mucho dolor a los desarrolladores de complementos y complementos, como el equipo de MarionetteJS. Tuvimos que rellenar los comportamientos con parches en nuestro código, de modo que podamos seguir siendo viables tanto para la versión 1.0 como para la 1.1 ... no es una situación divertida. Los efectos dominó de una biblioteca central como Backbone que tiene cambios rotundos son enormes ... no es solo Backbone lo que se ve afectado.

Estoy de acuerdo en que esto parece más un caso de "no quiero" en lugar de "no puedo". Los cambios importantes como https://github.com/jashkenas/backbone/pull/2461 no tienen un sentido real de urgencia y podrían haber esperado una actualización importante de la versión si no desea el problema 43.0.1.

Para mí, el mayor problema de que Backbone no respete semver (entre otras cosas) es enseñar y evangelizar a Backbone. No es bueno decirle a un grupo de estudiantes o clientes potenciales que todo en su pila va a funcionar de cierta manera ... excepto Backbone.

Siempre ha habido dos grandes advertencias al "evangelizar" Backbone: no es AMD listo para usar y no respeta SemVer, así que no se tome en serio los números de versión. Uno de esos está arreglado. Arreglemos el otro.

Honestamente, preferiría un esquema más simple que solo usara números de versión GRANDES y PEQUEÑOS, como lo hacen la mayoría de las aplicaciones de escritorio ... pero me preocuparía que rompa los administradores de paquetes y otras herramientas.

@jashkenas , siempre podríamos dejar el tercer dígito en .0 :)

Eso probablemente se correlacionaría semánticamente con SemVer un poco más cerca de lo que estamos haciendo ahora. Tal vez eso aplastaría algunas de las francotiradores criptopolíticos pasivo-agresivos sobre cómo de alguna manera es técnicamente incorrecto no seguir a SemVer.

Creo que el punto de Bob es correcto en el sentido de que es más importante articular claramente qué sistema seguimos, independientemente del sistema que sigamos.

PD: no quise dar a entender que el problema de @keithamus es pasivo-agresivo y lo siento si salió de esa manera. Definitivamente legítimo para discutir cómo Backbone comunica los cambios a los usuarios.

: +1: para semver. Lo que más me interesa es la versión de un software determinado, no como un índice de su progreso, sino de su compatibilidad.

En general, después de la 1.0 (cuando esperaría que las cosas estuvieran en su mayoría estables y funcionando), los números de versión carecen en gran medida de significado como indicadores de progreso. El software X en la versión 10 puede ser mucho menos maduro, tener menos funciones que el software Y en la versión 2. Si desea conocer el progreso de una pieza de software, debe consultar su registro de cambios o hoja de ruta.

Saber que Backbone (o lo que sea) está en 2.4.3 no significa nada en términos de sus características. Sin embargo, _debería_ significar que puedo actualizar desde mi 2.0.4 sin que nada se rompa.

Si seguimos estrictamente el control de versiones "semántico", probablemente ya sea Backbone.js 43.0.0, lo que no ayuda a nadie a evaluar el progreso real del proyecto.

Un problema menor o quizás inexistente. ¿No sigues a semver? Gran problema.

: +1 :, semver es imprescindible para un proyecto tan grande.

Estoy con @knowtheory. 43.0.0 parece un poco extraño, pero creo que 1.43.0 estaría bien y nadie se rompería por sorpresa después de npm install .

¿A quién le importa que los números de versión sean altos?
Es un estándar, si puede usarlo, debería usarlo.
Ni siquiera entiendo por qué esta discusión dura tanto.

: +1: Habría evitado algunos de los problemas en # 2996 y # 2997, y problemas que otros han tenido con varias otras versiones de Backbone.

@braddunbar eso (y el resto de las razones "en contra") parece que está valorando la estética del número de versión sobre su significado real.

Gracias, pero seguir estrictamente el control de versiones "semántico" no funcionaría muy bien para Backbone.

Creo que se trata más de que Backbone funcione bien para sus usuarios (con gestión de dependencias). Cuál siguiente semver garantizaría ...

Lanzamientos más frecuentes ayudarían a detectar errores más rápidos. Creo que es demasiado pedirle a la gente que ejecute constantemente versiones de borde de Backbone solo para obtener las correcciones de errores que necesitan.

+1 @derickbailey

Solo como ejemplo, estos son desde 1.1.0, la idea detrás de los lanzamientos de parches es que estas correcciones no deberían ser necesarias en absoluto.

https://github.com/marionettejs/backbone.marionette/commit/5a498d250d23a68c9c84a1362782edcf8774a1c8

https://github.com/marionettejs/backbone.marionette/commit/baed36bad8357e4379d4d2bc0460fd1375d2c85b

https://github.com/marionettejs/backbone.marionette/commit/e13e912bdda8e056c0e7b5e15d127eff158a48cb#diff -3c2771f47bdfe073ea95bfa54a37a972R167

Para paquetes en npm o bower, esto ni siquiera está sujeto a debate.

Cuando publica un paquete con npm o bower, semver es parte del contrato de API que celebra. Cuando rompes ese contrato, rompes otros módulos que dependen del tuyo. Rompe el código de producción que depende de su módulo.

La pregunta no es "¿deberíamos usar semver?" La pregunta es, "¿queremos ser buenos ciudadanos en el ecosistema?"

Si la respuesta es no, debe anunciarse en voz alta y clara, porque no es seguro instalar su paquete como lo haría con cualquier otro paquete que siga el contrato de API.

Cuando publica un paquete con npm o bower, semver es parte del contrato de API que celebra.

No, no es. npm install --save [email protected] no es un requisito oneroso.

@ akre54 Estoy interesado en tu perspectiva sobre semver Sé que @jashkenas piensa en ello, pero cuáles son las tuyas.

@ akre54 Sí, lo es. npm asume que todos los paquetes del repositorio siguen a semver . Así es como determina qué paquetes son compatibles con qué.

Desde el package.json doc:

"La versión debe ser analizable por node-semver, que se incluye con npm como dependencia. (Npm install semver para usarlo usted mismo)".

Si sus números de versión _lie_ cuando se interpretan como semver, ese no es un análisis correcto. Por lo tanto, está rompiendo el package.json y está rompiendo la compatibilidad con la forma en que las personas usan las versiones de paquetes en el ecosistema npm.

Eso no es solo una cuestión de preferencia personal. Es una cuestión de interoperabilidad de paquetes.

¿Es posible forzar que su paquete funcione bien si no usa semver? _Claro_, lo es, pero si no lo dice en voz alta y audaz en la parte superior de su archivo Léame, pocos usuarios sabrán que es necesario, y cuando introduzca un cambio importante, su código podría romperse muy fácilmente.

Una vez que publique sus paquetes en repositorios de paquetes, el control de versiones se convierte en parte del contrato de interoperabilidad. Ignora ese contrato a riesgo de sus usuarios.

npm install --save [email protected] no es un requisito oneroso.

Saber cuál de los miles de paquetes que entran en una aplicación completa tiene que hacer esto con _es_ un requisito oneroso. Obligar a los usuarios a bloquear estrictamente las versiones de todos sus paquetes porque algunos módulos no siguen las reglas _es_ un requisito oneroso, porque complica la cuestión de mantenerse al día con las correcciones de errores, parches de seguridad, etc.

Hay muy buenas razones para seguir a semver. "Mi número de paquete puede ser muy grande" es una razón terrible _no_ para usar semver. El seguimiento del progreso de su aplicación es una segunda razón lejana para las versiones de paquetes. La función más importante de la versión es saber, "¿funcionará esta versión con mi aplicación?"

Por cierto, si el número de su paquete fuera realmente grande, tal vez sea un olor a código. Solo tienes que subir la versión principal cuando realizas un _cambio importante_. Un cambio radical, por definición, es uno que _quebranta el principio abierto / cerrado_. Abierto para extensión, cerrado para cambios importantes. Todas las buenas API siguen el principio abierto / cerrado tan de cerca como es posible, para que los usuarios puedan seguir el ritmo de la API y los cambios no rompan el código existente.

Creo que la lección aprendida aquí es "no use ~ o ^ cuando ingrese Backbone a través de package.json"

@ akre54 Estoy interesado en tu perspectiva sobre semver

En general, estoy de acuerdo con los argumentos aquí, pero tengo que preguntarme si cambiar la versión principal es el mejor curso de acción en _todos_ cambios importantes (y nuevamente, con el subrayado siendo mayormente el área de la superficie, eso es _mucho_). Subrayado se usa en una gran cantidad de bibliotecas de terceros, y requerir que todos se mantengan al día con versiones enormes sería oneroso y peligroso. (¿Debería un paquete lanzado hoy depender de Underscore hasta la versión 2? ¿1.7? 1.6.x? ¿Debería fijar sus dependencias a expensas de tal vez requerir un subrayado separado del proyecto principal?)

Creo que la lección aprendida aquí es "no use ~ o ^ ​​cuando ingrese Backbone a través de package.json"

sí.

Creo que la lección aprendida aquí es "no use ~ o ^ ​​cuando ingrese Backbone a través de package.json"

He explicado anteriormente por qué esta no debería ser la lección para llevar.

Creo que la lección aprendida aquí es "no use ~ o ^ ​​cuando ingrese Backbone a través de package.json"

Eso es lo que hace, como consecuencia, para proteger su código de la rotura.

La lección sería más como "seguir semver es bueno para todos, no hacerlo no lo es".

Puedo apreciar el valor de las versiones "románticas". Lástima que no convivan muy bien.

Cabe señalar que siempre habrá proyectos que no sigan semver de manera muy estricta, y aquellos que lo intentan pero se quedan cortos, por lo que el sistema siempre se filtra un poco.

Al menos Backbone es generalmente muy bueno para no romper cosas.

@dgbeck las cosas se rompen todo el tiempo según las versiones, vea mi comentario anterior

Así que creo que el valor de seguir a semver del que realmente no se ha hablado es el hecho de que ustedes pueden impulsar funciones menores y correcciones de errores y permitir que las personas que dependen de él obtengan estos cambios de forma gratuita.

Para mí, esto es un gran valor agregado, pero obviamente esto tiene un costo de complejidad para el mantenedor.