Amqp: soporte de módulos go

👍 por adoptar semver. Anteriormente estaba cerrado en https://github.com/streadway/amqp/issues/312

Sospecho que depende completamente de cuál sea la respuesta al # 312 hoy. @streadway, ¿estás dispuesto a discutir esto una vez más?

Me complace discutir la propuesta de valor de cualquier cambio, incluidos los módulos Go o SemVer. Por favor, haga un caso apoyado con ejemplos.

El caso actual con el que estoy trabajando es la preferencia personal por el etiquetado xyz sobre el etiquetado de fecha + sha, por lo que sería más fácil presentar y discutir los pros y los contras de algo que no sea la preferencia con una tarea de mantenimiento o regresión como ejemplo.

@streadway gracias por la respuesta. Creo que el caso más importante que puedo presentar para Modules & SemVer es simplemente que el equipo de Go, la comunidad y la cadena de herramientas finalmente se han unido a ellos como la solución para la gestión de versiones y dependencias. Solo por esa razón creo que vale la pena adoptarlo.

Para agregar algo de color a esa declaración:

1. Go recomienda oficialmente usar SemVer https://github.com/golang/go/wiki/Modules#semantic -import-versioning
2. Los módulos de Go son el futuro (¡el futuro es ahora!) De la gestión de dependencias de Go

Este repositorio es uno de los casos más simples para los módulos (sin departamentos externos, sin lanzamientos existentes). El trabajo requerido será: agregar un go.mod, liberar v1.0.0 como etiqueta y una actualización menor a las pruebas de TravisCI para usar el modo de módulos para Go 1.11+.

Tener lanzamientos etiquetados SemVer también permitirá cualquier cambio futuro potencial que pueda venir. Aunque es poco probable, es bueno tener la flexibilidad.

Gracias por todo el trabajo en este paquete, y nuevamente estoy más que feliz de juntar los módulos PR cada vez que das el 👍.

Para una biblioteca que está en su séptimo año, los cambios importantes tampoco son probables, son necesarios ya que todos los errores inevitables en el diseño de API son ahora mucho más obvios que en los primeros días. Esto es incluso si ignoramos todos los cambios que provienen naturalmente del lado Go.

Lo que escuché es que se desean cambios importantes y la recomendación de importación de versiones sugiere usar un nombre de módulo diferente en lugar de usar una etiqueta. Esto efectivamente bifurca el repositorio usando diferentes ramas para respaldar las correcciones de errores en diferentes versiones principales.

Si el módulo es la versión v2 o superior, la versión principal del módulo debe incluirse como / vN al final de las rutas del módulo utilizadas en los archivos go.mod (p. Ej., Módulo github.com/my/mod/v2, require github.com/my/mod/v2 v2.0.0) y en la ruta de importación del paquete (por ejemplo, importar "github.com/my/mod/v2/mypkg").

Estoy de acuerdo con agregar un go.mod que simplemente contiene el nombre del paquete para rastrear HEAD (que es básicamente lo que hacemos hoy). Todavía no tenemos un proceso de publicación de confirmaciones etiquetadas documentado para nuestros colaboradores, por lo que el proceso y el valor de las confirmaciones de etiquetado aún no están claros. Documentar el proceso de publicación es un tema diferente.

En lugar de hablar sobre etiquetado y go.mod (que es fácil), analicemos cuáles son los cambios importantes deseados y si son lo suficientemente valiosos como para dividir las versiones en 2 módulos.

@michaelklishin, ¿ podría liderar un problema de amqp/v2 para recopilar una hoja de ruta para las mejoras de API? Tendré muy poco tiempo para trabajar en una v2, por lo que debemos ser realistas en cuanto a que los cambios importantes se implementarán, recibirán soporte y serán lo suficientemente valiosos como para garantizar un fork de este paquete en una nueva versión principal.

¿WDYT acerca de documentar el proceso de lanzamiento y el hito v2 primero?

Tal vez lo esté entendiendo mal, pero ¿cuál es la necesidad de bifurcar este repositorio para que funcione en una API v2?

Si el estado actual del maestro se etiquetó como v1, entonces cualquiera que quisiera bloquear sus importaciones a v1 puede hacerlo en su propio archivo go.mod. v2 puede desarrollarse en su propia rama y luego liberarse en master cuando esté listo.

También agregué mi soporte general para los módulos go; en realidad, es por eso que vine aquí para ver si se estaba trabajando en el soporte :)

Tal vez lo esté entendiendo mal, pero ¿cuál es la necesidad de bifurcar este repositorio para que funcione en una API v2?

Esta no es una "bifurcación de Github", sino la direccionabilidad de los módulos y el mantenimiento de más de una referencia HEAD para cada módulo. La recomendación es utilizar diferentes nombres de módulo para diferentes versiones principales.

• v1 (hoy) tendría un nombre de módulo de github.com/streadway/amqp .
• v2 (recomendado) tendría un nombre de módulo github.com/streadway/amqp/v2 .

Mantendríamos una rama v1 que tenía correcciones de errores y mejoras relacionadas con la v1, y una rama v2 con una API diferente que tendría correcciones de errores similares y mejoras relacionadas con la v2. Las confirmaciones de cada HEAD seguirán residiendo en este repositorio de git.

v2 puede desarrollarse en su propia rama y luego liberarse en master cuando esté listo.

¿Qué impacto tendría la fusión de v2 con master para los dependientes de la API v1 que no tienen un go.mod, o que no han agregado una declaración require en su go.mod?

Esta no es una "bifurcación de Github"

Veo. Mi experiencia con los módulos Go es principalmente del lado del consumidor.

¿Qué impacto tendría la fusión de v2 con master para los dependientes de la API v1 que no tienen un go.mod, o que no han agregado una declaración require en su go.mod?

Suponiendo que no hayan vendido, sería un cambio rotundo; pero ese es el riesgo que han estado tomando al no administrar las dependencias. Aunque puedo ver por qué ese es un problema legítimo para un paquete tan utilizado como este.

@streadway Me encantaría hacerlo, pero necesito entender el plan. Todavía no entiendo completamente por qué no puede haber un solo repositorio con múltiples sucursales, eso es lo que hacen todos los demás clientes. Los cambios de API cada pocos años son considerados razonables por la gran mayoría de la industria (o al menos la parte con la que interactúo). Este cliente y el protocolo que implementa se han mantenido notablemente estables a lo largo de los años.
Los clientes de 2012 todavía pueden conectarse y utilizar la mayoría de las funciones.

¿Por qué no mover la rama predeterminada a 1.x y retener la API actual, anunciar este cambio y en unos meses comenzar a integrar y documentar los cambios y diferencias de 1.x ? He estado haciendo algo similar con éxito durante años con otros clientes; así es como también se desarrollan los complementos RabbitMQ y tier 1.

Entiendo que algunos usuarios nunca verían ningún anuncio, no actuarían en consecuencia, pero si se trata de cambiar de rama, honestamente, es su problema.

Una solución alternativa que no me gusta es bifurcar este proyecto como en la bifurcación de GitHub, cambiar el nombre del paquete, moverlo a la organización RabbitMQ y adoptar las prácticas utilizadas para otros clientes y el propio RabbitMQ. Los usuarios actuales de este paquete continuarán usando este complemento, que solo obtendrá correcciones sin interrupciones.

Espero que esto cause mucha confusión al principio y, una vez que los tutoriales de RabbitMQ cambien al "nuevo cliente", este complemento eventualmente recibirá poca atención.

No me gusta esto en muchos niveles, especialmente dado que no planeamos ningún cambio drástico en la API.
Los clientes de Java y .NET han experimentado cambios más significativos en los últimos años, y se planean más. La respuesta de la comunidad ha sido realmente muy positiva porque todos quieren usar .NET Core, las últimas funciones del lenguaje Java, etc. con estos clientes.

Lamento haber secuestrado esta conversación, pero creo que primero debemos idear una estrategia de serie de múltiples lanzamientos y luego ver cómo encajarían los módulos Go, incluso si es el futuro inevitable del ecosistema Go.
@AlexRudd parece que estamos sugiriendo algo similar, ¿estás de acuerdo?

Este comentario y este comentario describen bastante bien la versión y el flujo de trabajo de ramificación utilizado en el proyecto Pika con respecto a la versión 0.13.0 ( stable ) y la próxima versión 1.0.0 ( master ).

Para este proyecto, en algún momento se puede agregar go.mod a master y etiquetar v1.0.0 . Luego, las correcciones seguirían el control de versiones semántico. Cuando se realiza un cambio incompatible con versiones anteriores en algún momento en el futuro en master , entonces el nombre v2 se agrega al nombre del módulo y la confirmación anterior se convierte en la base para futuras correcciones de v1 versiones. Las correcciones en la rama v1 (como se llame) se pueden fusionar hacia adelante en master según sea necesario. De todos modos, mis $ 0.02

¿WDYT acerca de documentar el proceso de lanzamiento y el hito v2 primero?

Nos salimos un poco del camino. Entonces, ¿eso es formalizar un proceso de lanzamiento potencial usando go mod y proponer cambios en la API que justificarían un lanzamiento v2?

Me interesaría conocer las experiencias de alguien al hacer lanzamientos regulares de un módulo Go. También cualquier ejemplo de otros repositorios que lo estén haciendo bien.

No veo la necesidad de discutir cambios importantes, y por lo tanto v2, en este contexto.

Mi comprensión de ¿Puede un módulo consumir un paquete que no ha optado por módulos? me hace pensar que todo lo que necesitamos es solo git tag v1.0.0 . Si no hacemos esto, cuando se requiera este paquete en un módulo, terminará con una _pseudo-versión como v0.0.0-20171006230638-a6e239ea1c69 _

Una vez que decidamos introducir v1 y, por lo tanto, comprometernos con una API estable (esta es una conclusión inevitable), es posible que queramos discutir los cambios importantes. Si nos encontramos en esa posición, y tenemos una v1, actualmente no la tenemos, tenemos la opción de tomar características caso por caso y decidir en ese momento si merecen una versión principal o no. . Sin semver, ni siquiera podemos empezar a tener esas conversaciones, que percibo como frustrantes para algunos.

¿Simplifiqué demasiado?

Enfatizo la compatibilidad con versiones anteriores en esta biblioteca para la simplicidad de la aplicación del cliente (siga el encabezado, obtenga correcciones) y la simplicidad del mantenedor (desarrolle en la cabeza, avance para las correcciones). Valoro la simplicidad de la aplicación cliente mucho más que la simplicidad del mantenedor, así que estoy dispuesto a adoptar cualquier proceso de lanzamiento que facilite la recepción de actualizaciones a esta biblioteca para los desarrolladores de aplicaciones.

Puede que valga la pena profundizar en mis opiniones. Pienso en la gestión de dependencias de dos formas: integrar continuamente los cambios para el desarrollo o garantizar la repetibilidad de la compilación para el lanzamiento. Tampoco necesitamos SemVer mientras las API diferentes (incompatibles con versiones anteriores) tengan nombres diferentes. Creo que la versión pinning hace recibir actualizaciones de dependencias como esta biblioteca con más fuerza. Sin control de versiones, es una cosa menos de la que preocuparse. "> = 1.0.0" es lo que hace esta biblioteca de forma predeterminada sin la complejidad incidental de comprender y seguir la ceremonia del número de versión .

En el trabajo, usamos módulos go, pero también queremos aceptar los cambios iniciales rápidamente. Para la integración continua, utilizamos una herramienta interna como https://dependabot.com/ que crea relaciones públicas para aumentar la versión para cada cambio anterior. Tengo la esperanza de que los mantenedores disciplinados podrían haber proporcionado una alternativa a la cantidad de abandono de versiones que enfrenta el desarrollo de aplicaciones, solo para mantenerse al día.

Para la repetibilidad de la versión, guardamos la aplicación construida en una versión de prueba, en lugar de intentar guardar todas las versiones de todas las dependencias. Esto significa que si queremos repetir un lanzamiento, ya tenemos el artefacto y no necesitamos rastrear las fuentes.

Con los módulos go, se documenta cómo se espera que tanto el cliente como el mantenedor administren los cambios v2 + . Seguir esas expectativas hace que mi opinión sea discutible, y eso simplifica las cosas a largo plazo tanto para los futuros mantenedores de esta biblioteca como para los desarrolladores de aplicaciones existentes.

Sin semver, ni siquiera podemos empezar a tener esas conversaciones, que percibo como frustrantes para algunos.

Podemos (y debemos) tener estas conversaciones sin SemVer; solo usaríamos una ruta de importación diferente en lugar de una etiqueta git.

El culto cargo de las versiones

Una lectura interesante, ¡gracias por vincular!

Por lo tanto, el enfoque que parece servir mejor a todos los posteriores sería agregar un archivo go.mod a la rama maestra para el módulo github.com/streadway/amqp , y luego, si hay razones convincentes para trabajar en una versión 2 de la API: bifurca el maestro, actualiza go.mod al módulo github.com/streadway/amqp/v2 y suéltalo como v2.0.0 cuando esté listo.

¿Eso suena bien?

Por lo tanto, el enfoque que parece servir mejor a todos los que se encuentran en la etapa posterior sería agregar un archivo go.mod a la rama maestra para el módulo github.com/streadway/amqp, y luego, si hay razones convincentes para trabajar en una versión 2 de la API: bifurque del maestro, actualice go.mod al módulo github.com/streadway/amqp/v2 y libérelo como v2.0.0 cuando esté listo.

Sí, eso suena bien. Creo que hoy podemos agregar go.mod sin etiquetas.

Basado en toda la conversación aquí, abrí # 394 que simplemente agrega go.mod y actualiza TravisCI para probar en modo de módulo para Go 1.11+.