No tengo conocimiento de una definición formal de “verificado”.
Todo el software es potencialmente defectuoso.
tests-passed tiene los commits más actualizados. beta solo recibe lanzamientos beta. stable solo recibe lanzamientos estables.
tests-passed es lo que se ejecuta en prácticamente todos los sitios alojados en discourse.org y en la gran mayoría de los sitios autohospedados.
@mcwumbly: ¿Tenemos un documento de “qué versión debo ejecutar”? Busqué un poco y no encontré nada. Todo lo que recuerdo es algo como esto de los anuncios de stable.
Estoy de acuerdo en que deberíamos tener un tema mejor sobre esto, donde podamos referenciar más claramente nuestra recomendación de estar en tests-passed.
Por separado, me tienta un poco deshacerme de beta (puede que inicie un nuevo tema al respecto).
También deberíamos explicar la diferencia entre las compilaciones y cómo cambiar la compilación en la que te encuentras en las instrucciones de instalación discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub. Acabo de revisarlo y no veo ninguna mención al respecto.
Lo separé (¡creo que es la primera vez que lo hago!), ya que el pobre alma todavía no puede saber si es “peligroso” actualizar, y esta discusión sobre cómo resolver el problema de que la gente no sepa si actualizar no está ayudando.
La otra cosa que preguntó, que es donde comenzó, y creo que es bastante razonable, es “¿Si estoy en la última beta, por qué necesitaría actualizar?”. Y lo anterior lo aborda de manera bastante directa.
No creo que debamos hacerlo. Queremos que la gente esté en tests-passed. Las instrucciones de instalación oficiales deben conducir a una instalación predeterminada con tantas configuraciones como queramos. Eso incluye la rama que se rastrea.
Siempre habrá personas que decidan usar, por ejemplo, la última versión estable. No tener una guía sobre cómo lograrlo en el lugar más intuitivo no hace que esas personas desaparezcan; simplemente les resulta un poco menos conveniente, y probablemente a veces significa que vienen aquí a preguntar, y otros dedican tiempo a responder la pregunta (una y otra vez).
Sin embargo, el argumento más sólido es que la guía puede mostrarles cómo hacerlo correctamente, lo que significa que podrán volver atrás más tarde si cambian de opinión. Si no lo saben, podrían terminar rompiendo su instalación, lo que será inconveniente tanto para ellos como para su comunidad.
Si INSTALL-cloud.md tiene una sección sobre cómo cambiar de rama, puede aclarar cuál es la predeterminada y por qué, dejando claro que la predeterminada es la más utilizada y la más fácil de soportar.
Estoy 100% de acuerdo con que haya una guía en Meta sobre cómo cambiar de rama. Simplemente no creo que pertenezca a la guía de instalación oficial, donde al 95% de las personas no les importa o no necesitan importarle.
Si Bob Básico está intentando instalar Discourse, solo quiere completar la instalación lo más rápido y fácilmente posible, para poder trabajar en su nuevo sitio. La información sobre cómo cambiar de rama solo le hará pensar más y le causará confusión.
Por otro lado, Ally Avanzada puede estar interesada en comprender cómo funcionan las ramas y cuál es la mejor para su sitio. Pero es probable que también esté investigando más antes de instalar Discourse, no simplemente revisando la guía de instalación.
De hecho, tal como está, recibimos ocasionalmente temas de usuarios que desean volver a la versión beta o estable y que fallan.
Incluirlo en la documentación de instalación estándar realmente abriría las compuertas, tanto por lo anterior como por los problemas de compatibilidad de complementos con las versiones anteriores.
Estoy de acuerdo. En general, siento que beta confunde más a la gente de lo que cumple una utilidad.
Creo que ayuda a trazar una distinción entre las cosas que usas y tienen significado internamente y las cosas que significan algo para terceros. La rama beta es un buen ejemplo de esto. Si bien puede tener alguna utilidad interna, tiene poca utilidad para terceros y a veces los confunde.
Me interesaría escuchar lo contrario, pero pensándolo ahora, no recuerdo a ningún autoalojador serio que realmente use beta de alguna manera significativa. “Bob Básico” realmente no sabe qué es una rama y probablemente no le importa (y está bien). “Ally Avanzada” usará tests-passed si es una persona o una PYME, y puede usar stable (o fijar commits) si es una empresa mediana o grande.
Mi sugerencia sería mantener todo a nivel de rama exactamente como está, pero simplemente decir públicamente “Tenemos dos ramas que puedes usar: tests-passed (la predeterminada y la mejor) y stable (si sabes lo que haces y tienes una necesidad particular)”.
Por mi parte, con solo tener el nombre de la rama tests-passed visible junto al nombre de la versión en el panel sería una mejora suficiente.
Totalmente de acuerdo. Cualquiera que quiera tomar una rama diferente, casi siempre la encontrará.
Si no pueden encontrarla con los recursos existentes (búsqueda, proyecto estándar de GitHub), ¿están realmente equipados con las habilidades necesarias para comprender completamente la diferencia entre las ramas, y mucho menos para desviarse de la seguridad de la predeterminada?
Claro, eso tiene sentido. Pero siento que estamos perdiendo la oportunidad de ayudar a la gente a entender la distinción entre las diferentes opciones aquí. No veo ningún inconveniente en decirle a los autoalojados que la opción predeterminada es tests-passed, que es ideal para la mayoría de los sitios y garantiza que obtengas las últimas correcciones de seguridad y actualizaciones. Si eres reacio al riesgo, puedes dejarlo en tests-passed y actualizar solo cuando se te solicite en el software, o una semana después de recibir la solicitud. De esa manera, otras personas descubren primero cualquier problema y se solucionan antes de que actualices.
Dado lo anterior, ¿hay razones legítimas para que los autoalojados cambien de tests-passed? Supongo que si tu sitio tiene muchos mods y se romperá si se actualizan el discurso principal o los complementos oficiales, ¿y no confías en ti mismo o en tus administradores para no actualizar? ¿O si estás configurando un entorno de desarrollo o staging?
Otro lugar para explicar esto podría ser en app.yml, que actualmente es bastante críptico porque solo se refiere a tests-passed y no menciona las opciones ni cuándo podrías cambiar a una diferente.
## ¿Qué revisión de Git debe usar este contenedor? (predeterminado: tests-passed)
#version: tests-passed
En mi opinión, usar algo que no sea tests-passed solo tiene sentido si estás en un servicio de alojamiento administrado o si: 1) tienes un equipo que administra tu comunidad (es decir, eres una empresa mediana o grande); y 2) tienes una razón específica para no estar en tests-passed, por ejemplo, tienes múltiples personalizaciones que pueden romperse.
Diría que ambas condiciones son necesarias, porque a menos que tengas un equipo administrando tu comunidad en el escenario de múltiples personalizaciones frágiles, tu problema no es el uso de tu rama, sino la gestión general de tu sitio (es decir, no es sostenible).
Incluso si ambas son ciertas, habría otras cosas a tener en cuenta primero, como tu política de actualización.
Creo que el problema es que si dijeras algo como “Puedes usar estable o tests-passed”, algunas personas pondrían stable porque suena “sensato” cuando probablemente no deberían usarlo.
¿Adónde va beta?
Para argumentar en contra de la rama beta, en varios contextos escritos y hablados, las principales confusiones que produce son:
La gente normalmente asocia el término “beta” con algo más vanguardista que el “estándar”. No es el caso aquí.
Algunas empresas consideran usarla porque parece un poco menos vanguardista que tests-passed y un poco más actualizada que estable, es decir, de nuevo, parece “sensato”. Pero en la mayoría de los casos no es una buena idea.
“beta” es un término utilizado tanto en los números de versión de Discourse como en el nombre de una rama de Discourse. He descubierto que esto confunde a algunas personas.
“Beta” probablemente disuada a algunas personas con conocimientos informáticos básicos como yo: el significado habitual es “todavía probando la calidad” en lugar de “todavía añadiendo funciones”.
Supongo que estoy pensando principalmente en los nombres de las versiones en lugar del nombre de la rama. Había asumido que estaba en una rama “beta” basándome en los nombres de las versiones (no lo estoy) hasta que lo comprobé ahora, así que nada de eso me disuadió…
Sí. Creo que es confuso (o puedo ver cómo podría ser confuso) que estés en tests-passed y la versión aparezca como “beta”, pero puedes hacer una actualización y obtener código nuevo que es la misma versión beta en la que ya estás. Y hay semanas y cientos de commits entre lanzamientos beta.
