Mysql: Por favor, etiquete un nuevo lanzamiento

Y algunos más seguirán antes de etiquetar otro lanzamiento .

Si te sientes valiente, usa la última tecnología (rama maestra) y da tu opinión.
Hicimos algunos cambios funcionales más grandes durante el ciclo actual, por ejemplo, compatibilidad con resultados múltiples (que debería ser bastante estable ahora) y cambios en la lógica de reintento (n.º 302) que probablemente necesite más ajustes (n.º 657) antes de que podamos lanzarlo. como estable .

Puede acelerar todo el proceso contribuyendo o simplemente abordando problemas generales que nos distraen de preparar el próximo lanzamiento.
Estamos buscando ansiosamente más colaboradores activos para este proyecto. AFAIK, los 3 miembros actuales del equipo trabajan en esto exclusivamente en su tiempo libre. Desafortunadamente, ninguno de nosotros actualmente parece tener mucho tiempo libre.
Si su empresa (dirigida a todos los que leen esto) depende de ello, mi consejo sería asegurarse de que alguien a quien se le pague por trabajar en esto regularmente durante el tiempo de trabajo .

Si el master actual es menos estable que la etiqueta v1.3 , entonces probablemente la sección de instalación de README debería mencionarlo. Tener una política de control de versiones explícita debería ser beneficioso para los usuarios.

¿Cuál es el estado más reciente de una posible versión v1.4? ¿Hay algún problema concreto que haga que esta versión sea un problema? ¿Cómo podría ayudar a que se produzca un nuevo lanzamiento?

Creo que podría tomar la última confirmación como inicio de, digamos, _v1.4_. Si las personas luego usan esta versión en su configuración de Dep, por ejemplo, como version=^v1 o incluso version=v1.4 y encuentran errores críticos, podríamos lanzar v1.4.1 y los usuarios obtendrán implícitamente la corrección del error; aparte de no cortar el lanzamiento, las personas para FUD no confían en branch=master sino en revision=X y luego se dan cuenta muy tarde de que ya hay una corrección de errores disponible para ellos.