Não há uma definição formal de “verificado” que eu conheça.
Todo software é potencialmente falho.
tests-passed tem os commits mais atualizados. beta recebe apenas lançamentos beta. stable recebe apenas lançamentos estáveis.
tests-passed é o que está em execução em praticamente todos os sites hospedados em discourse.org e na grande maioria dos sites auto-hospedados.
@mcwumbly – temos um documento “qual versão devo executar”? Procurei um pouco e não encontrei. Tudo o que me lembro é algo como isto de anúncios do stable.
Concordo que este é um assunto sobre o qual deveríamos ter um tópico melhor, onde possamos referenciar mais claramente nossa recomendação de estar em tests-passed.
Separadamente, estou um tanto tentado a remover beta (posso iniciar um novo tópico sobre isso).
Eu separei isso (acho que é a primeira vez que faço isso!), pois a pobre alma ainda não consegue dizer se é “perigoso” atualizar, e essa discussão sobre como resolver o problema das pessoas não saberem se devem atualizar não está ajudando.
A outra coisa que ele perguntou, que é onde ele começou, e acho que é bastante razoável, é “Se eu estiver na versão beta mais recente, por que precisaria atualizar?” E o acima aborda isso de forma bastante direta.
Não acho que devamos. Queremos que as pessoas usem tests-passed. As instruções de instalação oficiais devem levar a uma instalação padrão com o máximo de configurações correspondentes ao que queremos. Isso inclui o branch que está sendo rastreado.
Sempre haverá pessoas que decidem usar, por exemplo, a versão estável mais recente. Não ter um guia sobre como conseguir isso no local mais intuitivo não faz com que essas pessoas desapareçam; apenas torna as coisas um pouco menos convenientes para elas - e provavelmente, às vezes, significa que elas vêm aqui para perguntar, e outras pessoas gastam tempo respondendo à pergunta (repetidamente).\n\nProvavelmente, o argumento mais forte, no entanto, é que o guia pode mostrar a elas como fazer isso corretamente, o que significa que elas poderão reverter mais tarde se mudarem de ideia. Se elas não souberem, podem acabar quebrando sua instalação, o que será inconveniente para elas e para sua comunidade.\n\nSe o INSTALL-cloud.md tiver uma seção sobre como mudar de branch, isso pode esclarecer qual é o padrão e o porquê, deixando claro que o padrão é o mais utilizado e o mais fácil de dar suporte.
Fico 100% satisfeito com a existência de um guia na Meta sobre como alterar branches. Só não acho que pertença ao guia de instalação oficial, onde 95% das pessoas não se importam ou não precisam se importar.
Se o Bob Básico estiver tentando instalar o Discourse, ele só quer passar pela instalação o mais rápido e fácil possível, para que possa trabalhar em seu novo site. Informações sobre como alterar branches apenas o farão pensar mais e causarão confusão.
Por outro lado, a Ally Avançada pode ter interesse em entender como os branches funcionam e qual é o melhor para o site dela. Mas ela também provavelmente está fazendo mais pesquisas antes de instalar o Discourse, não apenas passando pelo guia de instalação.
De fato, como está, recebemos tópicos ocasionais de usuários querendo reverter para beta ou estável e falhando.
Colocar isso na documentação de instalação padrão realmente abriria as comportas, tanto devido aos problemas acima quanto aos problemas de compatibilidade de plugins com as versões mais antigas.
Concordo. No geral, sinto que beta confunde mais as pessoas do que cumpre uma utilidade.
Acho que ajuda a traçar uma distinção entre coisas que você usa e têm significado internamente e coisas que significam algo para terceiros. O branch beta é um bom exemplo disso. Embora possa ter alguma utilidade interna, tem pouca utilidade para terceiros e às vezes os confunde.
Teria interesse em ouvir o contrário, mas pensando nisso agora, não consigo me lembrar de um auto-hospedeiro sério que realmente use beta de alguma forma significativa. “Bob Básico” realmente não sabe o que é um branch e provavelmente não se importa (e tudo bem). “Ally Avançada” usará tests-passed se for um indivíduo ou PME, e pode usar stable (ou fixar commits) se for uma empresa de médio ou grande porte.
Minha sugestão seria manter tudo no nível de branch exatamente como está, mas apenas dizer publicamente “Temos dois branches que você pode usar: tests-passed (o padrão e o melhor) e stable (se você sabe o que está fazendo e tem uma necessidade específica).”
Do meu lado, apenas ter o nome do branch tests-passed visível ao lado do nome da versão no painel já seria uma melhoria suficiente.
Concordo totalmente. Qualquer um que queira usar um branch diferente, quase sempre o encontrará.
Se eles não conseguirem encontrá-lo com os recursos existentes (pesquisa, projeto padrão do GitHub), eles realmente possuem as habilidades necessárias para entender completamente a diferença entre os branches, quanto mais se desviar da segurança do padrão?
Claro, isso faz sentido. Mas sinto que estamos perdendo uma oportunidade de ajudar as pessoas a entender a distinção entre as diferentes opções aqui. Não vejo mal em dizer aos auto-hospedeiros que o padrão é tests-passed, que é ideal para a maioria dos sites e garante que você receba as últimas correções de segurança e atualizações. Se você for avesso ao risco, pode deixar em tests-passed e atualizar apenas quando solicitado no software, ou cerca de uma semana após receber o aviso. Dessa forma, outras pessoas descobrem quaisquer problemas primeiro e eles são corrigidos antes que você atualize.
Dado o acima, existem razões legítimas para auto-hospedeiros mudarem de tests-passed? Acho que se o seu site for muito modificado e quebrar se o Discourse principal ou os plugins oficiais forem atualizados, e você não confia em si mesmo ou em seus administradores para não atualizar? Ou se você estiver configurando um ambiente de desenvolvimento ou staging?
Outro lugar para explicar isso poderia ser em app.yml, que atualmente é bastante críptico porque se refere apenas a tests-passed e não menciona as opções ou quando você pode mudar para outra.
## Qual revisão Git este contêiner deve usar? (padrão: tests-passed)
#version: tests-passed
Na minha opinião, usar qualquer coisa que não seja tests-passed só faz sentido se você estiver em um serviço de hospedagem gerenciado ou: 1) se você tiver uma equipe gerenciando sua comunidade (ou seja, você é uma empresa de médio a grande porte); e 2) você tiver um motivo específico para não estar em tests-passed, por exemplo, você tem várias personalizações que podem quebrar.
Eu diria que ambas as condições são necessárias, porque a menos que você tenha uma equipe gerenciando sua comunidade no cenário de múltiplas personalizações frágeis, seu problema não é o uso do seu branch, mas o gerenciamento geral do seu site (ou seja, não é sustentável).
Mesmo que ambas sejam verdadeiras, haveria outras coisas a serem consideradas primeiro, como sua política de atualização.
Acho que o problema é que, se você dissesse algo como “Você pode usar stable ou tests-passed”, algumas pessoas colocariam stable lá porque soa “sensato” quando provavelmente não deveriam estar usando.
Onde vai o beta?
Para reforçar o argumento contra o branch beta, em vários contextos escritos e falados, as principais confusões que ele produz são:
As pessoas normalmente associam o termo “beta” a algo mais de ponta do que o “padrão”. Não é o caso aqui.
Algumas empresas consideram usá-lo porque parece um pouco menos de ponta do que tests-passed e um pouco mais atualizado do que stable, ou seja, novamente, parece “sensato”. Mas, na maioria dos casos, não é uma boa ideia.
“beta” é um termo usado tanto nos números de versão do Discourse quanto como nome de branch do Discourse. Descobri que isso confunde algumas pessoas.
“Beta” provavelmente afasta algumas pessoas semilettradas em computação como eu – o significado usual é “ainda testando a qualidade” em vez de “ainda adicionando recursos”.
Acho que estou pensando principalmente nos nomes das versões em vez do nome do branch. Eu tinha assumido que estava em um branch “beta” com base nos nomes das versões (não estou) até verificar agora, então nada disso me afastou…
Sim. Acho que é confuso (ou posso ver como pode ser confuso) que você esteja em tests-passed e a versão apareça como “beta”, mas você pode fazer um upgrade e obter novo código que é a mesma versão beta em que você já está. E são semanas e centenas de commits entre os lançamentos beta.
