Artículo escrito en febrero de 2018.

Go necesita agregar versiones de paquete.

Más precisamente, debe agregar el concepto de control de versiones al diccionario y las herramientas de trabajo de los desarrolladores de Go para que todos usen los mismos números de versión cuando mencionen qué programa construir, ejecutar o analizar. El comando go debería decir exactamente qué versiones de qué paquetes están en un ensamblaje particular.

La numeración de versiones le permite hacer ensamblajes reproducibles: si publico la última versión de mi programa, obtendrá no solo la última versión de mi código, sino también las mismas versiones exactas de todos los paquetes de los que depende mi código, de modo que crearemos archivos binarios completamente equivalentes.

El control de versiones también garantiza que mañana el programa construya exactamente lo mismo que hoy. Incluso si se lanzan nuevas versiones de dependencias, go no las usará sin un comando especial.

Aunque necesita agregar control de versión, no debe renunciar a las principales ventajas del comando go : es simplicidad, velocidad y comprensión. Hoy, muchos programadores no prestan atención a las versiones, y todo funciona bien. Si crea el modelo correcto, los programadores aún no prestarán atención a los números de versión, simplemente todo funcionará mejor y se volverá más claro. Los flujos de trabajo existentes apenas cambiarán. El lanzamiento de nuevas versiones es muy simple. En general, el control de versiones debe dejarse de lado y no quitarle la atención al desarrollador.

En resumen, debe agregar el control de versión del paquete, pero no romperlo y go get . En este artículo, sugerimos cómo hacer esto, y también demostramos un prototipo que puede probar ahora y que, espero, se convertirá en la base para una posible integración. Espero que este artículo sea el comienzo de una discusión productiva sobre lo que funciona y lo que no. Con base en esta discusión, haré ajustes tanto en mi propuesta como en el prototipo, y luego presentaré la propuesta oficial para agregar una función opcional a Go 1.11.

Esta propuesta retiene todos los beneficios de go get , pero agrega compilaciones reproducibles, admite control de versión semántico, elimina la comercialización, elimina GOPATH a favor de un flujo de trabajo basado en proyectos y proporciona una salida sin problemas de dep y sus predecesores. Sin embargo, esta propuesta aún se encuentra en una etapa temprana. Si los detalles no son correctos, los arreglaremos antes de que el trabajo entre en la distribución principal de Go.

Situación general

Antes de examinar la propuesta, veamos la situación actual y cómo terminamos en ella. Esta sección puede ser un poco demasiado grande, pero la historia trae lecciones importantes y ayuda a comprender por qué queremos cambiar algo. Si esto no le interesa, puede ir inmediatamente a la oferta o leer el artículo del blog que lo acompaña con un ejemplo .

Makefile , goinstall y go get

En noviembre de 2009, el compilador, el enlazador y varias bibliotecas se lanzaron con la versión inicial de Go. Para compilar y vincular los programas, era necesario ejecutar 6g y 6l , e incluimos ejemplos de makefiles en el kit. El shell de gobuild mínimo podría compilar un paquete y escribir el archivo MAKE correspondiente (en la mayoría de los casos). No había una forma establecida de compartir el código con otros. Sabíamos que esto no era suficiente, pero publicamos lo que teníamos, planeando desarrollar el resto junto con la comunidad.

En febrero de 2010, propusimos goinstall , un comando simple para descargar paquetes de repositorios de sistemas de control de versiones como Bitbucket y GitHub. Goinstall introducido convenciones sobre rutas de importación que ahora son generalmente aceptadas. Pero en ese momento, ningún código seguía estas convenciones; al principio, goinstall solo funcionaba con paquetes que no importaban nada excepto la biblioteca estándar. Pero los desarrolladores pasaron rápidamente a un acuerdo único que conocemos hoy, y el conjunto de paquetes Go publicados se ha convertido en un ecosistema holístico.

Goinstall también reparó los Makefiles, y con ellos la complejidad de las opciones de compilación personalizadas. Aunque a veces es inconveniente que los autores de paquetes no puedan generar código durante cada compilación, esta simplificación es increíblemente importante para los usuarios de paquetes: no tienen que preocuparse por instalar el mismo conjunto de herramientas que utilizó el autor. Esta simplificación también es crucial para el funcionamiento de las herramientas. Makefile es una receta necesaria paso a paso para compilar un paquete; y aplicar otra herramienta como go vet o autocompletar al mismo paquete puede ser bastante difícil. Incluso obtener dependencias correctamente, reconstruir paquetes si es necesario y solo si es necesario, es mucho más complicado con Makefiles arbitrarios. Aunque en ese momento algunas personas objetaron que se les estaba privando de la flexibilidad, pero mirando hacia atrás, queda claro que abandonar el Makefile fue el paso correcto: los beneficios superan con creces los inconvenientes.

En diciembre de 2011, en preparación para Go 1, presentamos el comando go , que reemplazó goinstall con go get .

En general, go get introducir cambios significativos: permitió a los desarrolladores de Go intercambiar el código fuente y usar el trabajo del otro. También aisló partes del sistema de compilación dentro del comando go , de modo que se hizo posible una automatización significativa con la ayuda de herramientas. Pero go get falta el concepto de control de versiones. En las primeras discusiones sobre goinstall, quedó claro: debe hacer algo con el control de versiones. Desafortunadamente, no estaba claro qué hacer exactamente. Al menos nosotros en el equipo de Go no entendimos esto claramente. Cuando go get solicitar un paquete, siempre obtiene la última copia, delegando las operaciones de descarga y actualización a un sistema de control de versiones como Git o Mercurial. Tal "trabajo ciego" ha llevado a al menos dos fallas significativas.

Control de versiones y estabilidad de API

El primer inconveniente importante de go get es que sin el concepto de control de versiones, no puede decirle al usuario nada sobre los cambios que puede esperar en esta actualización.

En noviembre de 2013, una versión de Go 1.2 agregó una entrada de preguntas frecuentes con tales consejos sobre el control de versiones (el texto no ha cambiado a la versión Go 1.10):

Los paquetes para uso general deben mantener la compatibilidad con versiones anteriores a medida que evolucionan. Las recomendaciones de compatibilidad de Go 1 son relevantes aquí: no elimine los nombres exportados, fomente el etiquetado de literales compuestos, etc. Si se requiere una nueva funcionalidad, agregue un nuevo nombre en lugar de cambiar el antiguo. En el caso de un cambio fundamental, cree un nuevo paquete con una nueva ruta de importación.

En marzo de 2014, Gustavo Niemeyer lanzó gopkg.in bajo la apariencia de "API estables para el lenguaje Go". Este dominio es una redirección de GitHub gopkg.in/yaml.v1 versión que le permite importar rutas como gopkg.in/yaml.v1 y gopkg.in/yaml.v2 para varias confirmaciones (posiblemente en diferentes ramas) de un repositorio de Git. Según las versiones semánticas, los autores deben, al realizar cambios críticos, lanzar una nueva versión principal. Por lo tanto, las versiones posteriores de la ruta de importación v1 reemplazan a las anteriores, y v2 puede proporcionar API completamente diferentes.

En agosto de 2015, Dave Cheney presentó una propuesta para el control de la versión semántica . En los siguientes meses, esto causó una discusión interesante: todos parecían estar de acuerdo en que el etiquetado semántico de versiones es una gran idea, pero nadie sabía cómo deberían funcionar las herramientas con estas versiones.

Cualquier argumento para las versiones semánticas será inevitablemente criticado con referencia a la ley de Hyrum :

El contrato de su API deja de ser importante con un número suficiente de usuarios. Alguien depende de cualquier comportamiento observado del sistema.

Aunque la ley de Hyrum es empíricamente correcta, el control semántico de versiones sigue siendo una forma útil de generar expectativas sobre la relación entre lanzamientos. Una actualización de 1.2.3 a 1.2.4 no debería romper su código, y una actualización de 1.2.3 a 2.0.0 puede muy bien. Si el código deja de funcionar después de actualizar a 1.2.4, lo más probable es que el autor acepte un informe de error y repare el error en la versión 1.2.5. Si el código dejó de funcionar (o incluso se compiló) después de actualizar a 2.0.0, entonces es mucho más probable que este cambio sea intencional y, en consecuencia, es poco probable que algo se arregle en 2.0.1.

No quiero concluir de la ley de Hiram que las versiones semánticas son imposibles. En cambio, creo que los ensamblajes deben usarse con cuidado, usando exactamente las mismas versiones de cada dependencia que el autor. Es decir, el ensamblaje predeterminado debe ser lo más reproducible posible.

Ensambles expendedores y reproducibles

El segundo gran inconveniente de go get es que sin el concepto de control de versiones, un equipo no puede proporcionar e incluso expresar la idea de una compilación reproducible. No puede estar seguro de que los usuarios estén compilando la misma versión de las dependencias de código que usted. En noviembre de 2013, se agregaron las siguientes preguntas frecuentes a las preguntas frecuentes para Go 1.2:

Si usa un paquete externo y teme que pueda cambiar inesperadamente, la solución más fácil es copiarlo en el repositorio local (Google utiliza este enfoque). Guarde una copia con una nueva ruta de importación que la identifique como una copia local. Por ejemplo, puede copiar original.com/pkg a you.com/external/original.com/pkg . Una de las herramientas para este procedimiento es el goven de Kit Rerik.

Keith Rarik comenzó este proyecto en marzo de 2012. La utilidad goven copia la dependencia en el repositorio local y actualiza todas las rutas de importación para reflejar la nueva ubicación. Tales cambios en el código fuente son necesarios, pero desagradables. Hacen que sea difícil comparar e incluir nuevas copias, y también requieren actualizar otro código copiado usando esta dependencia.

En septiembre de 2013, Keith presentó godep , "una nueva herramienta para arreglar las dependencias de los paquetes". El principal logro de godep fue lo que ahora llamamos proveedor, es decir, copiar dependencias en el proyecto sin cambiar los archivos de origen, sin soporte directo para las herramientas, a través de una determinada configuración de GOPATH.

En octubre de 2014, Keith propuso agregar soporte para "paquetes externos" a las herramientas Go para que las herramientas comprendan mejor los proyectos que utilizan esta convención. Para ese momento, varias utilidades de estilo godep ya habían aparecido. Matt Farina publicó una publicación godep "Viajando por el Mar de Go godep Managers" comparando a godep con godep , especialmente glide .

En abril de 2015, Dave Cheney introdujo gb , "una herramienta de compilación basada en proyectos ... con compilaciones repetidas a través de la venta de código fuente", de nuevo sin reescribir rutas de importación (otra motivación para crear gb era evitar el requisito de almacenar código en directorios específicos en GOPATH lo cual no siempre es conveniente).

Esa primavera, Jason Buberlie examinó la situación con los sistemas de gestión de paquetes Go, incluida la duplicación múltiple de esfuerzos y el vano trabajo en utilidades similares. Su encuesta dejó en claro a los desarrolladores que el soporte para la venta sin reescribir las rutas de importación debe agregarse al comando go . Al mismo tiempo, Daniel Theofanes comenzó a preparar especificaciones para un formato de archivo que describe el origen exacto y la versión del código en el directorio del proveedor. En junio de 2015, aceptamos la propuesta de Keith como un experimento de venta en Go 1.5 , que se incluyó por defecto en Go 1.6. Alentamos a los autores de todas las herramientas de venta a trabajar con Daniel para que adopten un único formato de archivo de metadatos.

La introducción del concepto de venta automática en Go permitió que herramientas como el vet analizaran programas de manera más competente, y hoy ha sido utilizado por una docena o dos administradores de paquetes o herramientas de venta. Por otro lado, dado que todos tienen diferentes formatos de metadatos, no interactúan y no pueden intercambiar fácilmente información de dependencia.

Más fundamentalmente, la venta automática es una solución incompleta al problema del control de versiones. Proporciona solo la reproducibilidad del ensamblaje, pero no ayuda a comprender las versiones del paquete y decidir cuál usar. Los gestores de paquetes como glide y dep agregan implícitamente el concepto de control de versiones a Go, configurando el directorio de proveedores de cierta manera. Como resultado, es posible que muchas herramientas en el ecosistema Go no puedan obtener la información de versión correcta. Está claro que Go necesita soporte directo para las versiones de paquetes.

Experimento oficial de gestión de paquetes

En la GopherCon 2016 en el Hack Day (ahora Día de la Comunidad), un grupo de activistas de Go se reunieron para debatir ampliamente los problemas de gestión de paquetes . Uno de los resultados fue la formación de un comité y un grupo asesor para llevar a cabo una serie de actividades con el objetivo de crear una nueva herramienta de gestión de paquetes . La idea era que una herramienta unificada reemplazara las existentes, aunque aún se implementaría fuera del kit de herramientas directas de Go utilizando catálogos de proveedores. El comité incluyó a Andrew Gerrand, Ed Muller, Jesse Frazel y Sam Boyer, liderados por Peter Burgon. Prepararon un borrador de especificación , y luego Sam y sus asistentes implementaron dep . Para una comprensión de la situación general, vea el artículo de Sam de febrero de 2016, "Así que desea escribir un administrador de paquetes", su publicación de diciembre de 2016 "Go Dependency Management Saga", y su discurso de julio de 2017 en GopherCon, "Una nueva era de administración de paquetes en Vete " .

Dep realiza muchas tareas: esta es una mejora importante sobre las prácticas actuales. Este es un paso importante hacia una solución futura, y al mismo tiempo un experimento, lo llamamos un "experimento oficial", que nos ayuda a comprender mejor las necesidades de los desarrolladores. Pero dep no dep un prototipo directo de la posible integración de los comandos go en el versionado de paquetes. Esta es una forma poderosa, flexible y casi universal de explorar el espacio de las decisiones de diseño. Es similar a los makefiles que peleamos al principio. Pero tan pronto como comprendamos mejor el espacio de las decisiones de diseño y podamos reducirlo a unas pocas funciones clave que deberían ser compatibles, esto ayudará al ecosistema Go a eliminar otras funciones, reducir la expresividad y adoptar convenciones vinculantes que hacen que las bases de códigos Go sean más consistentes y fáciles de entender.

Este artículo es el comienzo del siguiente paso después de dep : el primer prototipo de la integración final con el comando go , el equivalente por lotes de goinstall . Un prototipo es un comando separado que llamamos vgo : un reemplazo de go con soporte para el control de versiones de paquetes. Este es un nuevo experimento, y veremos qué sale de él. Al igual que durante el anuncio de goinstall , algunos proyectos y códigos ahora son compatibles con vgo , mientras que otros necesitan cambios. Eliminaremos algo de control y expresividad, tal como se eliminaron los archivos MAKE para simplificar el sistema y eliminar la complejidad para los usuarios. Lo que es más importante, estamos buscando pioneros que ayuden a experimentar con vgo para obtener la mayor cantidad de opiniones posible.

Iniciar un experimento con vgo no significa detener el soporte de dep : permanecerá disponible hasta que logremos una integración completa y abierta con go . También intentaremos hacer que la transición final de dep a integración go más fluida posible, en cualquier forma que tenga lugar esta integración. Los proyectos que aún no se han convertido a dep aún pueden beneficiarse de esta conversión (tenga en cuenta que godep y glide detenido el desarrollo activo y están alentando la migración a dep). Quizás algunos proyectos deseen cambiar directamente a vgo si esto satisface sus necesidades.

Oferta

La propuesta de agregar control de versiones al comando go consta de cuatro pasos. Primero, acepte la regla de compatibilidad de importación , que se indica en las preguntas frecuentes y gopkg.in: las versiones más nuevas del paquete con la ruta de importación especificada deben ser compatibles con versiones anteriores. En segundo lugar, adopte un nuevo algoritmo simple, conocido como elegir la versión mínima para determinar qué versiones del paquete se utilizan en este ensamblado. En tercer lugar, presente el concepto del módulo Go: grupos de paquetes que se versionan en su conjunto y declaran los requisitos mínimos que deben cumplir sus dependencias. Cuarto, determine cómo integrar todo esto en su comando go existente para que los flujos de trabajo básicos no cambien significativamente a partir de hoy. En el resto de este artículo, observamos cada uno de estos pasos. Se discuten con más detalle en otros artículos de blog .

Regla de compatibilidad de importación

El principal problema con los sistemas de administración de paquetes son los intentos de resolver incompatibilidades. Por ejemplo, la mayoría de los sistemas permiten que el paquete B declare que necesita el paquete D de la versión 6 o posterior, y luego permiten que el paquete C declare que requiere la versión D 2, 3 o 4, pero no la versión 5 o posterior. Por lo tanto, si desea utilizar B y C en su paquete, entonces no tiene suerte: no puede seleccionar ninguna versión de D que satisfaga ambas condiciones, y no puede hacer nada.

En lugar de un sistema que inevitablemente bloquea el ensamblaje de programas grandes, nuestra propuesta introduce una regla de compatibilidad de importación para los autores de paquetes:

Si los paquetes antiguos y nuevos tienen la misma ruta de importación, el nuevo paquete debe ser compatible con versiones anteriores del paquete anterior.

La regla repite las preguntas frecuentes mencionadas anteriormente. Ese texto terminó con las palabras: "En caso de un cambio radical, cree un nuevo paquete con una nueva ruta de importación".Hoy, para un cambio tan importante, los desarrolladores cuentan con el control de versión semántico, por lo que lo integramos en nuestra propuesta. En particular, el número de la segunda y las versiones principales posteriores se pueden incluir directamente en la ruta:

 import "github.com/go-yaml/yaml/v2" 

En el control de versión semántico, la versión 2.0.0 significa un cambio radical, por lo que se crea un nuevo paquete con una nueva ruta de importación. Como cada versión principal tiene una ruta de importación diferente, un ejecutable específico de Go puede contener una de las versiones principales. Esto es esperado y deseable. Dicho sistema admite el ensamblaje de programas y permite que partes de un programa muy grande se actualicen independientemente de v1 a v2 de forma independiente.

El cumplimiento de los autores con la regla de compatibilidad de importación elimina los intentos de resolver incompatibilidades al simplificar exponencialmente el sistema general y reducir la fragmentación del ecosistema del paquete. Por supuesto, en la práctica, a pesar de todos los esfuerzos de los autores, las actualizaciones dentro de la misma versión principal a veces rompen los paquetes del usuario. Por lo tanto, no debe actualizar con demasiada frecuencia. Esto nos lleva al siguiente paso.

Selección mínima de versión

, dep cargo , . , . -, « » - , - . , - , , , . -, , , «, X», X .

Nuestra propuesta utiliza un enfoque diferente, que yo llamo la selección de la versión mínima . Por defecto, se utiliza la versión más antigua permitida de cada paquete. Esta decisión no cambiará mañana, porque es imposible publicar una versión anterior. Aún mejor, es trivial que un administrador de paquetes determine qué versión usar. Llamo a esto la elección de la versión mínima, porque los números de versión seleccionados son mínimos, y también porque el sistema en su conjunto probablemente también sea mínimo, evitando casi toda la complejidad de los sistemas existentes.

Elegir la versión mínima permite que los módulos especifiquen solo los requisitos mínimos para las dependencias. Estas son respuestas claramente definidas y únicas tanto para las actualizaciones como para las operaciones de degradación, y estas operaciones son realmente efectivas. Este principio permite al autor de todo el módulo indicar la versión de las dependencias que desea excluir, o indicar el reemplazo de una dependencia específica con su fork, que se encuentra en el almacenamiento local o se publica como un módulo separado. Estas excepciones y reemplazos no se aplican cuando un módulo se crea como una dependencia de otro módulo. Esto les da a los usuarios un control completo sobre cómo se ensamblan sus propios programas, pero no sobre extraños.

Seleccionar la versión mínima proporciona ensamblajes reproducibles por defecto sin un archivo de bloqueo.

La compatibilidad de importación es clave para hacer que la versión mínima sea fácil de seleccionar. Los usuarios ya no pueden decir "no, esta es una versión demasiado nueva", solo pueden decir "no, es demasiado antigua". En este caso, la solución es clara: use la versión más nueva (mínima). Y las versiones más nuevas por convención son reemplazos aceptables para las más antiguas.

Definición de módulos Go

Un módulo Go es una colección de paquetes con un prefijo de ruta de importación común conocido como ruta de módulo. Un módulo es una unidad de control de versiones, y las versiones se escriben como cadenas semánticas. Al desarrollar con Git, los desarrolladores definen una nueva versión semántica del módulo agregando una etiqueta al repositorio de Git del módulo. Aunque se recomienda encarecidamente que especifique versiones semánticas, también se admiten enlaces a confirmaciones específicas.

En el nuevo archivo, el go.modmódulo define los requisitos mínimos de versión para otros módulos de los que depende. Por ejemplo, aquí hay un archivo simple go.mod:

 // My hello, world. module "rsc.io/hello" require ( "golang.org/x/text" v0.0.0-20180208041248-4e4a3210bb54 "rsc.io/quote" v1.5.2 ) 

Este archivo define un módulo identificado por la ruta rsc.io/helloy depende de otros dos módulos: golang.org/x/texty rsc.io/quote. El ensamblaje del módulo en sí siempre usará ciertas versiones de las dependencias necesarias enumeradas en el archivo go.mod. Como parte de un conjunto más grande, solo puede usar una versión más nueva si alguna otra parte del conjunto lo requiere.

Los autores marcan sus lanzamientos con versiones semánticas, y vgorecomiendan usar versiones marcadas, en lugar de confirmaciones arbitrarias. El módulo rsc.io/quoteque viene github.com/rsc/quotetiene versiones marcadas, incluida 1.5.2. Sin embargo, el módulo aún no tiene golang.org/x/textversiones marcadas. Para nombrar confirmaciones sin etiquetar, la pseudo versión v0.0.0-aaaammddhhmmss-commitdefine una confirmación específica en una fecha determinada. En las versiones semánticas, esta línea corresponde a la versión preliminar v0.0.0 con el identificador aaaammddhhmmss-commit . Las reglas semánticas de precedencia de versiones reconocen dichos prelanzamientos como anteriores a la versión v0.0.0 y realizan comparaciones de cadenas. El orden de fechas en la pseudo versión garantiza que la comparación de cadenas coincida con la comparación de fechas.

Además de estos requisitos, los archivos go.modpueden indicar las excepciones y reemplazos mencionados en la sección anterior, pero nuevamente solo se aplican cuando se construye un módulo aislado, y no cuando se construye como parte de un programa más grande. Todo esto se demuestra en los ejemplos .

Goinstally viejogo getLas herramientas de control de versiones, como gity hg, se llaman para descargar el código , lo que genera muchos problemas, incluida la fragmentación. Por ejemplo, los usuarios sin bzrno pueden descargar el código de los repositorios de Bazaar. A diferencia de este sistema, los módulos Go siempre se emiten a través de HTTP en forma de archivos zip. Anteriormente, había go getequipos especiales para sitios de alojamiento de código populares. Ahora tienen vgoprocedimientos API especiales para recibir archivos de estos sitios.

La presentación uniforme de los módulos en forma de archivos zip permite implementar trivialmente un protocolo y un servidor proxy para cargar módulos. Las empresas y los usuarios individuales tienen diferentes razones para iniciar dichos servidores proxy, incluida la seguridad y el deseo de trabajar con copias en caché en caso de que se eliminen los originales. Con un proxy disponible go.mod, los directorios de proveedores ya no son necesarios para garantizar la accesibilidad y determinar qué código usar.

El equipo go

go . , , go build , go install , go run go test , . golang.org/x/text Go .

— GOPATH . go.mod , , go.mod , , . git clone , cd , . . GOPATH.

?

También publiqué un Go Versioning Tour con una demostración de cómo usarlo vgo. Ese artículo te dice cómo descargar y comenzar a usar hoy vgo. Otra información en otros artículos . Estaré encantado de comentar.

Por favor, intente vgo . Comience a etiquetar versiones en repositorios con etiquetas semánticas. Crea archivos go.mod. Tenga en cuenta que si un archivo vacío en el repositorio go.mod, pero hay dep, glide, glock, godep, godeps, govend, govendoro el archivo de configuración gvt, y luego vgolas utiliza para rellenar el archivo go.mod.

Me alegra que Go esté dando este paso tan retrasado en el soporte de versiones. Algunos de los problemas más comunes que enfrentan los desarrolladores de Go son la falta de compilaciones reproducibles, el completo desconocimiento de las etiquetas de lanzamiento desde el exterior go get, la incapacidad de GOPATH para reconocer diferentes versiones del paquete y la incapacidad para trabajar en directorios fuera de GOPATH. El diseño ofrecido aquí elimina todos estos problemas y más.

Pero probablemente me equivoque en algunos detalles. Espero que los lectores puedan ayudar a mejorarlo probando el prototipo vgoy participando en discusiones productivas. Me gustaría que Go 1.11 venga con soporte preliminar para los módulos Go, como una especie de demostración, y luego Go 1.12 salió con soporte oficial. En versiones posteriores, eliminaremos el soporte para la versión anterior que no es de versióngo get. Pero este es un plan agresivo, y si para la funcionalidad correcta necesita esperar a versiones posteriores, que así sea.

Me preocupa mucho la transición de las viejas go gete innumerables herramientas de venta al nuevo sistema modular. Este proceso es tan importante para mí como la funcionalidad correcta. Si una transición exitosa significa esperar lanzamientos posteriores, nuevamente, que así sea.