Underscore: El guión bajo no sigue a SemVer

Para citar https://github.com/jashkenas/backbone/issues/2888#issuecomment -29076249:

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

También vale la pena leer el resto del comentario, incluso si no está de acuerdo.

https://github.com/jashkenas/coffeescript/issues/3352#issuecomment -34217211 también

@ akre54 Tengo curiosidad por saber qué piensa sobre el hecho de que otros proyectos como Lo-Dash (alternativa de subrayado) y ExosJS (alternativa de Backbone) puedan seguir a semver.

Dado que esos reemplazos directos _pueden seguir a semver_, ¿eso no arroja una llave en la excusa impulsada por el núcleo Underscore/Backbone?

Cosas de pareja.

Lo-Dash, en su mayor parte, se apega a los caminos pavimentados por Underscore, por lo que tiene la ventaja de esperar hasta un lanzamiento de Underscore para impulsar una versión mejorada para la paridad de características. Las diferencias con el guión bajo tienden a estar más en la categoría de mejoras y menos en cambios significativos de última hora.

Lo-Dash agrega mucho más código de protección para bc a expensas del desorden de códigos, mientras que Underscore se esfuerza por ser breve. Es más fácil salirse con la suya con unas pocas líneas de código adicional cuando la biblioteca es más grande para empezar (Lo-Dash registra 8.7k líneas frente a 1.4k para el guión bajo). También hay mucho más mucking interno que se puede hacer en Lo- Dash ya que gran parte de la lógica es interna.

También está escrito de manera desproporcionada por un colaborador (usted), mientras que los cambios de Underscore tienden a provenir de un conjunto mucho más diverso de colaboradores, lo que significa que las nuevas funciones pueden aparecer en cualquier momento y, a veces, los grandes cambios de funciones y los cambios incompatibles con versiones anteriores llegan en momentos inoportunos para un calendario de lanzamiento.

Como anécdota, tengo la sensación de que Underscore también tiene la desventaja de que se usa en muchos más proyectos para principiantes que Lo-Dash (por su propia naturaleza, Lo-Dash tiende a atraer a los desarrolladores que necesitan su poder). Un desarrollador más avanzado se sentirá más cómodo lidiando con las consecuencias de los cambios importantes y puede comprender un poco más su razonamiento.

Por último, como coautor y colaborador principal de Exoskeleton, seré el primero en decirles que tampoco hemos estado siguiendo a semver. También tenemos las ventajas de Lo-Dash como se describe anteriormente.

Lo-Dash, en su mayor parte, se apega a los caminos pavimentados por Underscore, por lo que tiene la ventaja de esperar hasta un lanzamiento de Underscore para impulsar una versión mejorada para la paridad de características. Las diferencias con el guión bajo tienden a estar más en la categoría de mejoras y menos en cambios significativos de última hora.

¿Qué tiene eso que ver con la estrategia de versiones de Underscore? Lo-Dash aumenta las versiones después de semver, por lo que está en v2.x pasando a v3.x.

Lo-Dash agrega mucho más código de protección para bc a expensas del desorden de códigos, mientras que Underscore se esfuerza por ser breve.

¿Qué tiene que ver el código de protección o ser conciso con la estrategia de versión?

Es más fácil salirse con la suya con unas pocas líneas de código adicional cuando la biblioteca es más grande para empezar (Lo-Dash registra 8.7k líneas frente a 1.4k para Underscore).

Lo-Dash tiene documentos en línea, LOC no es relevante para el control de versiones.

También hay mucho más mucking interno que se puede hacer en Lo-Dash, ya que gran parte de la lógica es interna.

¿No se puede decir lo mismo del guión bajo?

También está escrito de manera desproporcionada por un colaborador (usted), mientras que los cambios de Underscore tienden a provenir de un conjunto mucho más diverso de colaboradores, lo que significa que las nuevas funciones pueden aparecer en cualquier momento y, a veces, los grandes cambios de funciones y los cambios incompatibles con versiones anteriores llegan en momentos inoportunos para un calendario de lanzamiento.

Es por eso que Underscore tiene mantenedores para aceptar/rechazar o posponer hasta una versión futura.
Una vez más, no es relevante para el control de versiones.

Como anécdota, tengo la sensación de que Underscore también tiene la desventaja de usarse en muchos más proyectos para principiantes que Lo-Dash (por su propia naturaleza, Lo-Dash tiende a atraer a los desarrolladores que necesitan su poder).

No estoy de acuerdo, Lo-Dash tiene miles de dependientes y no todos pueden ser expertos en eso.

Un desarrollador más avanzado se sentirá más cómodo lidiando con las consecuencias de los cambios importantes y puede comprender un poco más su razonamiento.

Debido a que Lo-Dash sigue a Semver, los desarrolladores no tienen que lidiar con las consecuencias hasta que saltan a una actualización de versión principal. A diferencia de Underscore, Lo-Dash no cambiará porque usaron un ~ para el rango de versión del paquete.

Por último, como coautor y colaborador principal de Exoskeleton, seré el primero en decirles que tampoco hemos estado siguiendo a semver.

Entonces deberías eliminar eso de su comercialización.

No creo que haya ninguna razón por la que Underscore no pueda seguir a Semver.
No seguirlo es un perjuicio para sus usuarios :frowning:

Si desea ser incluido en npm o bower, no está sujeto a debate. Debes usar semver. Estás haciendo una promesa implícita de seguir a Semver, y si no lo haces, eso rompe el código de las personas sin previo aviso, y eso está mal visto por casi todo el mundo.

Estamos hablando de una elección que rompe el código de producción. No está bien jugar un juego descuidado con el tiempo y el dinero de otras personas.

Eso significa que sus números de versión aumentan más rápido. ¿Así que lo que? es un numero Eso es mucho mejor que romper el carrito de compras de producción de alguien.

+1 por sever

Personalmente, no creo que sea "genial" poner _personal_ en un informe de error. O lo hace o no sigue el control de versiones semántico. Estas son las razones, bang, bang, bang, por las que sería una biblioteca aún mejor si lo hiciera. Estas son las razones, bang, bang, por las que es factible que los mantenedores incrementen el número de versión de manera congruente con semver.

Después de eso, depende de los mantenedores. Si no está de acuerdo con su postura, hay bibliotecas alternativas para usar. Puede bifurcar el proyecto (como lo han hecho otros). Puedes escribir una publicación de blog tan personal como quieras.

Pero tratemos de tener un desacuerdo civil.

No entiendo @raganwald. ¿Quién se está poniendo personal?

No estoy atacando a nadie. Estoy señalando que semver es parte del contrato de API que celebra cuando publica un paquete en npm o bower.

Si rompes ese contrato, rompes el código de otras personas. Eso no es cool.

npm funciona muy bien porque todos estamos de acuerdo en algunas reglas que hacen que nuestros módulos funcionen bien entre sí. Si rompe esas reglas, rompe otros módulos que intentan funcionar con el suyo. Rompe las aplicaciones de producción que dependen de su código.

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

El punto clave es que en un proyecto como Underscore, _cada_ cambio es perjudicial para alguien. Si eliminamos una protección nula de _.extend (para usar un ejemplo aleatorio) porque está causando un error para alguien y crea un error para otra persona, ¿eso es un parche? ¿Es esa una versión menor? ¿Importante?

Para Underscore y Backbone, no creo que sea irrazonable fijar sus dependencias. Seguir a semver no es un requisito para publicar en un empaquetador.

El punto clave es que en un proyecto como Underscore, cada cambio afecta a alguien.

Estás saltando a un extremo para justificar tu posición. La realidad es que es un equilibrio. Hay API populares, casos extremos y comportamiento documentado. Es muy posible pasar un período de tiempo sin actualizar una versión principal simplemente corrigiendo errores y agregando funcionalidad.

Lo que significa es que los mantenedores tienen que pensar y planificar. Esto significa que es posible que deba crear una hoja de ruta para funciones o cambios que no se pueden abordar sin romper la compatibilidad con versiones anteriores y eso está bien.

Underscore ha mejorado los lanzamientos de parches e introducido importantes cambios importantes. Esto es algo que los mantenedores pueden controlar totalmente.

Para Underscore y Backbone, no creo que sea irrazonable fijar sus dependencias.

Seguro que debe haber un mensaje/advertencia en la documentación.

@akre54 Cambiar características _no documentadas_ o _errores no documentados_ puede romper el código que se basa en ellos, pero los usuarios confían en características y errores no documentados bajo su propio riesgo.

Ignorar a semver pone en peligro a _todos los usuarios_ de su API. La gente corrige errores en grandes proyectos de código abierto que siguen a semver todo el tiempo, pero _es realmente raro ver grandes números de versión en el ecosistema npm_.

¿Porqué es eso?

Porque _todas las buenas API siguen el principio abierto/cerrado_ (abierto para la extensión, cerrado para romper los cambios) tanto como sea posible, para que los usuarios puedan seguir el ritmo de la API y los cambios no rompan el código existente.

Para agregar a las anécdotas, mi código también se rompió por golpes de subrayado en el pasado. Hemos recurrido a asignar node_modules para evitarlo porque --save --save-exact no es suficiente. Si una dependencia de segundo nivel se basa en el guión bajo y usa una versión ^x.y.z , su aplicación aún no funciona.

En cuanto a los números de versión que indican el progreso, no me importa. Usar la versión 2.1.3 o 143.3.2 no hace ninguna diferencia para mí. El progreso y la madurez de la biblioteca no se miden en números de versión. Simplemente no quiero una llamada telefónica el domingo por la tarde porque alguien actualizó una dependencia que se basa en underscore@^x.y.z .

:pulgar arriba: Sí. @braddunbar destaca un punto que aún no he abordado: ignorar a semver convierte a su paquete en un paquete peligroso y virulento, porque ese cambio radical podría persistir _en cualquier lugar_.

_Definitivamente es un requisito oneroso_ obligar a los usuarios a buscar fallas en el código de terceros que depende de su paquete roto.

En mi opinión, el progreso y la madurez reales de la biblioteca se miden en confiabilidad, y semver contribuye en gran medida a alcanzar ese objetivo.

Seguro que debe haber un mensaje en la documentación.

Definitivamente. Estoy feliz de agregar uno si eso es lo que decidimos.

No estoy en contra de un mejor sistema de lanzamiento (Dios sabe que es un fastidio esperar meses para que se implemente tu pequeña corrección de errores), pero no estoy seguro de que "seguir a Semver" sea _la_ única respuesta correcta.

En este momento, no creo que importe si es la única respuesta correcta. Es _es_ la respuesta aceptada por la comunidad.

No creo que nadie haya dicho que "seguir a Semver" sea la única respuesta correcta para un mejor sistema de publicación. Lo que dijimos es que es el contrato API de npm, y que romper ese contrato hace daño.

@jdalton y @dilvie ¿Cómo propondría que gestionáramos los lanzamientos? ¿Qué pasa con la aceptación de funciones? "Usar semver" realmente no nos dice nada.

¿Deberíamos retrasar características como _.matches unos meses para que podamos esperar las correcciones de errores del código actual, o deberíamos lanzarlo ahora y dejar que la gente resuelva los problemas de implementación?

Creo que semver simplemente no se aplica completamente aquí.

Autopromoción desvergonzada: use la próxima actualización https://github.com/bahmutov/next-update para probar primero si las dependencias se pueden actualizar sin romper su proyecto. Constantemente encontré cambios importantes en diferentes módulos a pesar de haber cambiado *.*.x , por lo que ahora no confío en ninguna versión autodeclarada.

¿Crees que este proyecto es un copo de nieve? Lo-Dash es básicamente Underscore++, y seguir a semver no es un problema para @jdalton.

Aceptar nuevas funciones:

¿Rompe el contrato API existente?

¿Sí? - aumentar el número de versión principal.
¿No? - aumentar el número de versión menor.

Aceptar correcciones de errores/parches menores:

¿Rompe el contrato API existente?

¿Sí? - aumentar el número de versión principal.
¿No? - número de versión del parche de choque.

La forma en que elija programar los lanzamientos oficiales depende totalmente de usted. Solo asegúrese de que el control de versiones sea compatible con semver para no romper el código de otras personas.

De acuerdo con @dilvie , por ejemplo, https://github.com/jashkenas/underscore/compare/1.3.3...1.4.0 probablemente debería haber sido un gran bache ya que eliminamos el soporte para arreglos dispersos. La próxima versión debería ser un gran avance, ya que agregaremos una tonelada de azúcar nueva a través lookupIterator y soltaremos iteradores nativos.

Si la documentación de una función tiene que cambiar es claramente un cambio importante

Tuve una breve discusión sobre esto en JSconf este año. No tengo tiempo para entrar en detalles aquí, pero:

deje de combinar la "versión de versiones" de cara a humanos con la "compatibilidad de API" de cara a la computadora (o realmente, de cara al sistema de compilación). solo para.

Versión: "Esto que me gusta tiene nuevas características, o algo más que debería interesarme cuando tenga tiempo". Hay un nuevo iPhone. Hay un nuevo OS X. Hay un nuevo Ember. Hay un nuevo informe revisado sobre el esquema de lenguaje algorítmico.

Compatibilidad API: "Esto se actualizó para corregirproblema, y ​​esto puede romper el caminoejercita esa cosa. Se reemplazó el enchufe de alimentación del iPhone. OS X desaprobó las bifurcaciones de recursos. Ember desaprobó un estilo de nombres de acción. El esquema ahora distingue entre mayúsculas y minúsculas.

Lo último ocurre _durante_, o _junto a_ lo primero; pero el primero no depende necesariamente de este último ni está relacionado con él. Deben ser rastreados, y (si realmente vamos a _especificar_ un sistema de control de versiones, Jesús) especificados, por separado. (El concepto de 'versión semántica' popular en la comunidad de JS es _particularmente_ obtuso y terrible; pero, de nuevo, no es algo en lo que quiera entrar en detalle en el hilo de comentarios de Issue de otra persona).

tl; dr: No están arruinando su ecosistema al elegir su propio camino. (_Especialmente_ cuando ese camino es terriblemente defectuoso.) Desearía que más proyectos lo hicieran. Ve a usar otra cosa, si estás tan fuera de forma por eso.

@elliottcable : estuvo de acuerdo con la cara humana frente a la computadora ... Siempre que la cara humana no se parezca en nada a la cara de la computadora, de modo que la combinación sea menos problemática.

Tal vez llame al próximo lanzamiento de cara humana algo así como "copo de nieve" en lugar de nnn

Aunque totalmente en desacuerdo con lo último. Cuando pretendes seguir un contrato de API y luego lo rompes, las cosas se rompen. A otras personas les cuesta tiempo real y dinero real. Con un proyecto tan popular como el guión bajo, potencialmente hay mucho daño real.

¿Rompe el contrato API existente?

Vuelve a los primeros argumentos de este hilo. "Todo en Underscore es básicamente un área de superficie", ergo, todo, documentado o no, es parte de su contrato de API. Cualquier cambio es un cambio para todos.

Lo-Dash, siendo "Subrayado ++" no se ocupa de tantos cambios en las funciones porque puede seguir de manera segura detrás del Subrayado en la elaboración de funciones principales. Las mejoras de Lo-Dash se encuentran principalmente bajo el capó o en la adición de algunos métodos, sin repensar fundamentalmente sus características.

@akre54

¿Cómo propondría que manejáramos los lanzamientos? ¿Qué pasa con la aceptación de funciones? "Usar semver" realmente no nos dice nada.

Puede aceptar una nueva API o incluso algunas mejoras a la API existente. Si agrega una nueva API o mejoras (que no rompen la compatibilidad), es una actualización de versión menor.

¿Deberíamos retrasar características como _.matches unos meses para que podamos esperar las correcciones de errores del código actual, o deberíamos lanzarlo ahora y dejar que la gente resuelva los problemas de implementación?

Creo que _.matches es bastante sencillo. Siempre habrá correcciones de errores.

Creo que semver simplemente no se aplica completamente aquí.

Seguro que sí. Estás comenzando a preocuparte por el ciclo de lanzamiento, que es independiente de semver, pero te seguiré allí.

@dilvie : voy a quedarme fuera del resto del argumento, pero agregando esto: realmente, realmente me gusta tu sugerencia de ir con la convención 'nombre de la versión'. (=

Para la parte de cara humana, soy un gran admirador de las versiones de estilo less :

> less --version
less 418
Copyright (C) 1984-2007 Mark Nudelman

less comes with NO WARRANTY, to the extent permitted by law.
For information about the terms of redistribution,
see the file named README in the less distribution.
Homepage: http://www.greenwoodsoftware.com/less

… combínelo con un nombre bonito, para que quede más claro que estamos hablando de una versión “interesante”, no de compatibilidad API, y obtendrá una combinación ganadora.

+1 para subrayado 42: "Silly Sheltie".

(En cuanto a la parte que enfrenta el sistema de compilación, tengo algunas opiniones controvertidas sobre la compatibilidad API generativa y automatizada. Saquemos esta mierda de las manos de los mantenedores falibles, por favor, y ataquémosla con análisis estático o rastreo dinámico).

@akre54

Lo-Dash, siendo "Subrayado ++" no se ocupa de tantos cambios en las funciones porque puede seguir de manera segura detrás del Subrayado en la elaboración de funciones principales.

¿Y eso que significa? Lo-Dash se ocupa de _más cambios_ y sigue su propio control de versiones separado de Underscore. Lo-Dash ha cambiado tanto que ha tenido que ofrecer una compilación compatible con Underscore para continuar con su apoyo de ser un reemplazo directo. Tenemos diferentes características , métodos y diferentes preocupaciones de compatibilidad API.

Las mejoras de Lo-Dash se encuentran principalmente bajo el capó o en la adición de algunos métodos, sin repensar fundamentalmente sus características.

Ese tampoco es el caso. Lo-Dash se mueve a un ritmo más rápido y choca contra la espalda con más frecuencia. Es por eso que estamos ~v2.x pasando a ~v3.x. Lo-Dash es similar a un guión bajo. Si Lo-Dash puede seguir a Semver, también lo puede hacer Underscore. Lo he hecho durante ~ 2 años ahora. Sus argumentos simplemente fracasan frente a la realidad.

He recorrido este camino antes, así que puedo ayudarlos a llegar allí también.
Para empezar, el próximo lanzamiento de Underscore sería un gran 2.0.

Tengo curiosidad por saber cómo creen todos que debería definirse "romper el cambio". _Cada_ nuevo cambio de función en el guión bajo es un cambio importante para otra persona.

Tomemos como ejemplo todos los cambios recientes a _.each . ¿Deberíamos haber chocado cuando cambiamos el valor de retorno de _.each para devolver la lista original ? ¿Es esto una corrección de errores? ¿Una nueva característica? ¿Un cambio incompatible con versiones anteriores? Devolvió undefined antes, por lo que es poco probable que rompiera el código de alguien.

¿Deberíamos haber chocado cuando permitimos que el ayudante interno each se reasignara externamente ? ¿Podría eso haber descifrado el código de alguien? Ninguna API pública cambió allí.

Cambiar _.each para evitar arreglos dispersos y usar bucles for en lugar de forEach nativos obviamente es perjudicial para algunos, pero dado que los arreglos dispersos están muertos, ¿a quién le importa realmente? ¿Es algo por lo que deberíamos impulsar una versión principal? ¿Es esto una corrección de errores?

Creo que estamos atrasados ​​en un aumento de versión principal (han sucedido muchas cosas en 219 confirmaciones ). Una versión 2.0 y una solidificación de nuestra política de versiones contribuirían mucho en este sentido.

@akre54

Cada nuevo cambio de función en el guión bajo es un cambio importante para otra persona.

No necesariamente.

Tomemos como ejemplo todos los cambios recientes en _.each. ¿Deberíamos haber chocado cuando cambiamos el valor de retorno de _.each para devolver la lista original? ¿Es esto una corrección de errores?

No es una corrección de errores, es una mejora. ¿Es ininterrumpido?-- Probablemente sea un cambio seguro porque es poco probable que se haya confiado en el valor de retorno de _.each y no es algo que los desarrolladores hayan informado como un obstáculo al cambiar a Lo-Dash. En caso de duda, póngase del lado de romper, o pruebe las aguas con un lanzamiento RC. Si el cambio fuera para permitir la salida anticipada de _.each , diría que fue un cambio rotundo definitivo, ya que los desarrolladores se encontraron con eso al usar CoffeeScript.

¿Deberíamos haber chocado cuando permitimos que el interno de cada ayudante fuera reasignado externamente? ¿Podría eso haber descifrado el código de alguien? Ninguna API pública cambió allí.

Diría que cae bajo detalles de implementación no documentados. En ese momento, el cambio no permitía nada nuevo porque Underscore aún se ramificaba para métodos nativos. Este cambio se incluye en el grupo más grande de cambios en la publicación 1.6.0, por lo que puede aterrizar en un 2.0.

Cambiar _.each para evitar arreglos dispersos y usar bucles for en lugar de forEach nativos obviamente es perjudicial para algunos, pero dado que los arreglos dispersos están muertos, ¿a quién le importa realmente? ¿Es algo por lo que deberíamos impulsar una versión principal? ¿Es esto una corrección de errores?

Puede verse como una corrección de errores, pero definitivamente es un cambio importante. Esta es una de las cosas con las que se encuentran los desarrolladores cuando cambian a Lo-Dash. Debido a cómo solía ser Underscore, usando nativo cuando estaba disponible, enmascararía el uso escaso de matrices y los desarrolladores solo encontrarían el problema si probaran en navegadores más antiguos. Sin embargo, con este cambio, los desarrolladores recibirán una alerta sobre el uso de su matriz dispersa antes, en los navegadores modernos, por lo que existe la posibilidad de que su código que funcionaba anteriormente tenga un problema.

Creo que estamos atrasados ​​en un aumento de versión principal (han sucedido muchas cosas en 219 confirmaciones). Una versión 2.0 y una solidificación de nuestra política de versiones contribuirían mucho en este sentido.

:+1:

cambio de última hora (plural cambios de última hora)

(informática) Un cambio en una parte de un sistema de software que potencialmente hace que otros componentes fallen; ocurre con mayor frecuencia en bibliotecas compartidas de código utilizadas por múltiples aplicaciones
"No es posible corregir las entradas antiguas sin un cambio importante, así que vuelva a asignar las antiguas a las nuevas en import lib".

Algo de esto requiere algo de reflexión y juicio. Puede ser cierto que todos los cambios rompen el código de alguien, pero si todos los participantes acuerdan usar el principio abierto/cerrado como guía para lo que constituye romper, la vida de todos será más fácil.

Por lo tanto, agregar cualquier propiedad o método a la API generalmente no es un cambio importante (la API está abierta para la extensión, pero cerrada a cambios incompatibles con versiones anteriores).

Los cambios en las firmas de funciones requieren más reflexión.

¿Deberíamos haber chocado cuando cambiamos el valor de retorno de _.each para devolver la lista original?

¿Fue esa una característica documentada de la API que sirvió para algún propósito? Por ejemplo, algunas funciones devuelven undefined cuando las entradas pasadas no darían como resultado una salida sensible. Ese no parece ser el caso con each ... Entonces, probablemente no se rompa.

Evitar arreglos dispersos, por otro lado, tiene un mayor potencial para cambiar los valores de retorno en los que confían los desarrolladores, así que claramente, ese es un cambio importante, y a cualquiera que haya usado arreglos dispersos le importa.

Es posible que las matrices dispersas no sobrevivan a ES6, pero aún no están muertas.

@akre54
A veces, la respuesta a si un cambio se está rompiendo o no no es sencilla. En esos casos, el contexto, la historia y los datos ayudan. Es una suerte que haya podido usar Lo-Dash como campo de pruebas para nuevas funciones y ver qué cambios hacen tropezar a los desarrolladores provenientes de Underscore. El subrayado puede, a su vez, usarlo para ayudar a tomar decisiones informadas sobre el impacto de los cambios.

Como mínimo, el siguiente semestre ayudará a evitar que los cambios importantes se filtren en los lanzamientos de parches y animará a los desarrolladores a pensar en el impacto de sus cambios. Eso es una victoria para todos.

@jdalton , acto de clase. :)