Discourse não envia um release LTS

Geral
1

Não estava ciente da compatibilidade com o discourse, então é algo sobre o qual precisarei me aprofundar.

Gostaria de abordar isso, porque parece haver uma grande desconexão entre como a equipe do Discourse pensa sobre o estável e como o restante da comunidade do discourse/maior comunidade de administradores de fóruns pensa sobre a oferta estável do Discourse.

Principais razões pelas quais o estável não atende à definição de LTS.

1) O estável é ativamente desencorajado pela equipe sempre que é mencionado

Não quero necessariamente citar usuários individuais, mas aqui está uma seleção de postagens da equipe para mostrar o tema:

Note que em alguns aspectos tests-passed é mais estável que stable, pois é o que discourse.org executa, então é o mais bem testado.

Assim, o Discourse está em um estado de beta perpétuo, o que significa que estamos sempre trabalhando em novos recursos e refinamentos. Em nosso caso, beta não significa instável; hospedamos sites com milhões de visualizações de página mensais em nossas versões tests-passed e beta.

O canal estável não é necessariamente mais “estável” do que tests-passed. É mais sobre a ideia de que os bugs são conhecidos e serve como um ponto de verificação para um conjunto específico de recursos e melhorias. Com tests-passed, novos bugs podem ser introduzidos e, em seguida, corrigidos alguns commits depois.

A mensagem tem sido consistentemente que o Discourse está em “beta perpétuo”, o que não é a experiência que os usuários de produção/não desenvolvedores desejam ter.

Em uma rápida busca no DuckDuckGo pelos dez primeiros links para “discourse stable”, nenhum deles parece defender o uso do estável. Portanto, independentemente de sua qualidade real, se a equipe está universalmente guiando as pessoas para longe do estável, isso cria uma impressão negativa nas mentes das pessoas de que não é adequado para o propósito.

O estável pode ser ótimo, mas se nos dizem repetidamente que é melhor não usá-lo, não o consideraremos para implantação séria.

2. Um LTS recebe correções de bugs além de apenas correções de bugs de segurança

Um LTS é algo que não recebe atualizações de recursos, mas recebe correções de bugs. De acordo com os próprios comentários da equipe, no Discourse não parece haver esforço para fazer backport de correções de bugs para problemas não relacionados à segurança. Talvez isso não seja verdade, mas é o que nos foi dito.

3. Um LTS tem etapas de instalação diretas

O guia de instalação nem sequer menciona a existência do estável.

4. Um LTS é amplamente utilizado

Antes da sua postagem, eu não tinha ouvido falar de nenhum uso generalizado do branch estável. Ele também está sendo usado amplamente na prática? Dado o quão escondido ele está, duvido, mas não tenho métricas para dizer. Este é um fator importante porque dá às pessoas confiança para usar o estável para suas implantações de produção.

5. Um LTS tem um ciclo de lançamento claro e notas de atualização

Não vejo nenhum local central onde o estável esteja sendo claramente documentado. (Posso estar apenas perdendo!)

Minhas expectativas para um LTS são uma página que descreva:

  • Versão de lançamento ativa atual
  • Notas de lançamento incluindo:
    • Principais alterações/recursos entre as versões LTS
    • Etapas de migração da versão LTS anterior (especialmente alterações drásticas a serem observadas)
    • Duração de suporte ativo planejada para cada versão

ex: mediawiki, mas na verdade qualquer LTS de código aberto importante tem páginas semelhantes.

Essa documentação me ajuda a planejar quando há uma alteração drástica que exigirá tempo de inatividade e/ou intervenção manual.

6. Um LTS não tem alterações drásticas importantes dentro de um ciclo de lançamento

Isso pode muito bem ser o caso para o estável, mas estou muito acostumado a apertar o botão de atualização e o fórum cair para ter certeza. Acho que o que estou procurando aqui são avisos mais claros ao passar de versões que quebram algo.

7. Um LTS fornece avisos de depreciação de API para pelo menos um ciclo de lançamento LTS completo

Estes devem ser medidos no ritmo de um ano ou mais, em oposição a um mês ou mais.

8. Um LTS é escalonado / tem períodos de suporte sobrepostos

Qualquer LTS grande terá um período de suporte sobreposto entre duas versões LTS. O estável parece apenas fazer uma troca binária para a próxima versão. (Minha impressão também pode estar incorreta devido à falta de uma página de documentação centralizada)

9. É simples atualizar de não-LTS para LTS

Não há necessidade de suportar o retrocesso, mas quando um LTS está disponível, não está claro como mudar limpa e corretamente os branches para o LTS. Parece que há algumas postagens no fórum sobre isso, mas novamente, nenhuma documentação centralizada que eu pude encontrar.

Sou um fã do Discourse, mas este é um ponto de dor comum que eu e muitas outras pessoas encontramos. O que o estável é agora é apenas um branch, não um LTS.

4 curtidas
2

Movi isto para um tópico próprio, parece não relacionado ao empacotamento de plugins.

3 curtidas
3

Se considerarmos a carinha triste no painel do administrador em comparação com tantos commits atrasados em “atualizar discourse”
a parte crítica de atualização faz parte de tests-passed e se você “Atualizar Tudo” prontamente após a carinha feliz para a carinha triste, você estará sincronizado com tests-passed

4

Eu acho que esta atualização específica requer reconstrução a partir do console. Duas vezes.

1 curtida
5

O Discourse parece ter uma velocidade bastante alta em termos de mudanças e um roteiro ambicioso.

Para dar suporte a isso, ele precisa de muito feedback do usuário. Acho que há uma estratégia implícita clara para promover tests-passed, pois isso apoia o feedback antecipado sobre novas mudanças.

Em troca, o usuário recebe software gratuito e novos recursos. É uma espécie de pacto. Acho que, com o tempo, esse acordo provou ser bem-sucedido.

A versão estável não ajuda muito no desenvolvimento, então pode não ser do interesse comercial promovê-la tanto (apenas minha opinião, não falo pela CDCK de forma alguma).

O outro problema com a versão estável é este, e é ainda mais significativo:

Geralmente há muitas mudanças entre as versões estáveis, incluindo depreciações significativas e mudanças de API. O envolvimento em tests-passed como desenvolvedor, administrador de site ou criador de temas dá a você a chance de lidar com as mudanças em pequenas partes, em vez de ter uma montanha enorme para escalar cada vez que você atinge o próximo marco estável.

Para suportar esses grandes saltos, você provavelmente precisará de um site de staging e um monte de casos de teste para percorrer.

Se você não possui personalizações próprias, pode optar pela versão estável, mas dependerá muito de outros sobre os quais você pode não ter influência para garantir que quaisquer complementos que você esteja usando sejam mantidos adequadamente para sua próxima atualização. Você pode descobrir que alguns elementos perdem o suporte quando chega a hora de atualizar e, nesse ponto, pode se encontrar em apuros. Você também pode descobrir que o desenvolvedor não suporta a versão estável de forma alguma e pode ter que fazer um fork e preparar um “corte” do plugin para suportar sua versão estável. (no entanto, há um bom sistema de fixação em vigor, então não é uma grande quantidade de trabalho)

A outra peça de significado no Discourse é que ele é muito intensivo em testes unitários, então o branch test-passed geralmente é muito bom da perspectiva de estabilidade.

4 curtidas
6

Dado que a gerência se recusa a desfazer mudanças impopulares como o empacotamento de plugins, não acho que essa parte seja precisa. Talvez de uma perspectiva de QA, mas mesmo assim tive vários bugs bem complicados que não foram corrigidos no passado. No final das contas, percebo que são eles que estão investindo tempo e dinheiro nisso, então eles podem tomar suas decisões, mas na minha opinião, não acho que seja uma estratégia para obter mais feedback.

Acho que a razão mais realista pela qual eles não apoiam um LTS adequado é que isso custaria tempo de alguém da equipe gerenciando/documentando-o. É um recurso que beneficia principalmente os auto-hospedeiros, então imagino que seria considerado uma perda de tempo para eles. Mas é um recurso meio que esperado e não tê-lo é uma desvantagem real quando os administradores de fóruns escolhem seu software de fórum, já que outros contemporâneos têm ofertas mais estáveis.

7

Pelo contrário, acho que o empacotamento de plugins é precisamente para promover o seu uso e, como resultado, obter mais feedback.

8

A gerência mencionou especificamente problemas com a incompatibilidade de versões afetando a produtividade da equipe de desenvolvimento no outro tópico. O que é uma justificativa válida, mas não a melhor maneira de resolver o problema raiz, como discutido no outro tópico.