RFC: Uma nova estratégia de versionamento para Discourse

Dev
22

Ok, mas acho que então entendo o problema ainda menos :confused:

No final das contas, não importa muito, de acordo com os últimos comentários do @david, então, apenas para concluir.

O modelo proposto é de lançamento mensal, mais 2 versões esr, então, por exemplo, para 2026:

  • 2026.1
  • 2026.2
  • 2026.3
  • …
  • 2026.8
  • 2026.9
  • 2026.10
  • …

Então, assumindo que estamos em outubro de 2026 e .2 e .8 são versões esr, isso significa 4 versões suportadas.

E meu pensamento foi: não seria mais fácil ter versões trimestrais, ou seja, para 2026:

  • 2026.1
  • 2026.2
  • 2026.3
  • …

E ainda assim apenas a versão atual e a anterior seriam suportadas, então em outubro de 2026, seriam 2.

E todo o raciocínio foi que talvez isso facilitasse tanto para desenvolvedores quanto para usuários. Mas como mencionado acima: @david esclareceu que lançamentos menos frequentes não são uma opção.

2 curtidas
23

Entendido. É mais ou menos assim que eu esperava. De fato, neste caso, um pouco de suporte de ferramentas seria bom, pelo menos a médio prazo.

Da forma como eu conceptualizo, é: você está em um canal de lançamento específico (latest, release, esr), e normalmente você passaria relativamente rápido para o próximo lançamento, então receber uma mensagem e/ou notificação quando o novo lançamento estiver disponível e ter um único comando para mudar para ele seria ótimo. E para casos em que você atrasou a adoção de um novo lançamento, também seria bom ser lembrado quando o lançamento atualmente em uso se tornar obsoleto/não suportado. Pontos extras se a respectiva ferramenta também pudesse permitir que você mudasse rapidamente os canais de lançamento :slightly_smiling_face:

Mas entendo se essa não for a prioridade máxima no momento, e você ainda recomenda que as pessoas permaneçam no test-passed/latest.

Entendo. No contexto do meu trabalho, lançar um recurso para os clientes é considerado “rápido” :sweat_smile:

Além disso, como mencionado acima, meu pensamento era que mudar para um cronograma trimestral realmente facilitaria a sua vida (e a vida dos desenvolvedores de plugins/temas), porque há menos branches em manutenção. Então, se esse não for o caso, acho que realmente não faz sentido para você :slightly_smiling_face:

6 curtidas
24

Não vejo nenhum benefício para este esquema de versionamento baseado em ano que você propõe. Mantenha os números de versão compatíveis com SemVer!

25

O SemVer em si não foi realmente projetado para grandes aplicações. Entendo que ele é muito mais voltado para bibliotecas consumidas por software e, em particular, a lógica de numeração de versão é construída em torno da API do pacote.

Poderíamos aplicar o SemVer às nossas APIs, embora. Ter garantias mais fortes em torno das APIs que o Discourse expõe é certamente uma conversa que vale a pena ter, mas acho que é separada desta.

Agora, entendo que você não disse que deveríamos estar em conformidade com o SemVer – você apenas disse que deveríamos continuar usando números que são compatíveis com o sistema de numeração especificado pelo SemVer.

  1. Um número de versão normal DEVE ter a forma X.Y.Z, onde X, Y e Z são inteiros não negativos e NÃO DEVEM conter zeros à esquerda. X é a versão principal, Y é a versão secundária e Z é a versão de correção. Cada elemento DEVE aumentar numericamente. Por exemplo: 1.9.0 → 1.10.0 → 1.11.0.

Acho que a sugestão de “zeros à esquerda” é a única coisa que estaríamos quebrando se seguíssemos esse caminho.

Fora isso, acho que qualquer biblioteca SemVer ainda seria capaz de analisar os números de versão que estamos sugerindo e ordená-los corretamente.

Tudo isso de lado, você pode compartilhar mais sobre por que você acha que ser compatível com um sistema de numeração SemVer tem valor?

2 curtidas
26

O OP diz que você não está usando zeros à esquerda, se eu entendi corretamente.

Eu acho que também foi proposta uma razão convincente para usar zeros à esquerda (ordenar por versões). Os zeros à esquerda são o plano atual? (Eu ainda gosto de versões mensais em vez de versões seriais).

3 curtidas
27

O objetivo do SemVer é que o número da versão comunique informações úteis. A única informação comunicada pelo seu esquema proposto é a órbita da Terra ao redor do Sol. Essa informação não é muito útil para o consumidor do software.

Se por algum motivo eu quisesse saber a data de lançamento, eu olharia o lançamento e obteria a data completa.

Não exatamente. O ponto é comunicar a natureza do lançamento ao usuário.

Se o lançamento for um aumento de versão de patch, isso comunica que a alteração não contém nada que se espera que afete o fluxo de trabalho dos usuários do software.

Se o lançamento for um aumento de versão menor, isso comunica que a alteração inclui a adição de novos componentes voltados para o usuário, mas nada que quebre os fluxos de trabalho existentes dos usuários do software.

Se o lançamento for um aumento de versão principal, isso comunica que a alteração inclui mudanças que podem quebrar os fluxos de trabalho existentes dos usuários do software.

A determinação de qual dos componentes da versão deve ser incrementado é mais clara em um produto de software com uma única interface de usuário, mas os princípios permanecem os mesmos mesmo para um produto de software como o Discourse, onde há uma variedade de níveis de interfaces e tipos de consumidores (por exemplo, desenvolvedores de plugins, consumidores de API, equipe do fórum, usuários finais).

Mesmo que a escolha de qual componente incrementar seja um pouco mais subjetiva neste projeto de software, ainda resulta em o número da versão ter significado em vez de ser apenas um número arbitrário, como é o caso da sua proposta.

2 curtidas
28

Eu propus isso alguns posts acima.

Ao contrário do semver, o esquema de numeração de versão proposto deixa imediatamente claro se uma versão ainda é suportada (como o Ubuntu). Como isso também depende da órbita da Terra ao redor do sol, isso faz sentido.

Isso é claramente direcionado a pacotes e bibliotecas. Qualquer lançamento do Discourse inclui mudanças que podem quebrar os fluxos de trabalho existentes dos usuários do software. Eu já vi até patches de segurança fazerem isso. Semver não é utilizável para aplicações complexas.

Sim, realmente, veja

Uma vez que você identifica sua API pública, você comunica as mudanças nela com incrementos específicos no seu número de versão.

5 curtidas
29

Apenas para enfatizar um ponto que pode se perder, acho que o Discourse faz um ótimo trabalho aqui. Uma melhoria seria, pelo menos, destacar os tópicos que você já escreveu que descrevem alterações e possíveis interrupções dentro desse ciclo de atualização. Por exemplo, com o lançamento 3.5, tive que abrir as notas de lançamento, clicar no blog e, em seguida, clicar no link sobre o empacotamento de plugins com o Discourse core para captar esse detalhe de que deixar esses plugins dentro do meu arquivo de configuração poderia impactar as atualizações.

Seria ótimo extrair esse tipo de nota para uma página/tópico para lançamentos ESR, mesmo que seja apenas um conjunto de links para tópicos existentes que devem ser revisados antes de realizar uma atualização ESR.

Isso pode estar além do escopo deste tópico, no entanto - meu feedback sobre a mudança de versionamento é que eu a recebo bem e aprecio a transparência aqui. Acho que esta seria uma ótima melhoria que simplificaria as coisas, ao mesmo tempo que nos daria mais opções para auto-hospedagem.

Obrigado!

4 curtidas
30

Sim, e é uma ideia tão boa que acho que o op deveria ser editado para refletir isso!

3 curtidas
31

Os zeros à esquerda e se devemos ou não buscar sincronização com os meses de forma mais explícita estão sendo considerados. @david compartilhará uma atualização assim que o grupo que trabalha nisso chegar a uma decisão.

7 curtidas
32

Essa não é a informação importante para um mantenedor de fórum avaliando uma nova versão.

Não, realmente. Você está perdendo o ponto principal do SemVer ao se recusar a entender que “API” na verdade significa apenas a interface. Não há absolutamente nenhuma razão pela qual o espírito do SemVer não possa ser usado na versionamento de qualquer tipo de software.

33

Acho que teremos que concordar em discordar neste ponto @per1234.

Aqui está uma discussão relacionada no repositório do GitHub para semver com uma resposta de um dos mantenedores:

Semver não é realmente útil para “aplicativos de usuário final”, é mais útil para bibliotecas que as pessoas usam como dependências para seus projetos.

4 curtidas
34

Não importa realmente se é uma biblioteca ou uma aplicação maior. Um esquema de versionamento semântico funciona perfeitamente bem para uma aplicação grande. Ele pode até ser usado para uma coleção de aplicações empacotadas em uma plataforma, mas aqui se torna bastante difícil de lidar.

A principal questão é se você vai seguir o caminho da depreciação suportada em uma versão e apenas a remoção dela na próxima principal. Ter funcionalidade depreciada, mas suportada, pode exigir bastante esforço. Quando você vai fazer alterações em seu modelo de dados persistido, a depreciação pode se tornar impossível. Se isso acontecer, você nem consegue fazer uma versão menor com funcionalidade depreciada e salta instantaneamente para a próxima principal. Esta é a parte onde aplicações grandes geralmente têm problemas. Você passa de 3.0.0 para 3.0.1 para 4.0.0 porque não consegue fornecer retrocompatibilidade. Se você frequentemente tem alterações que quebram a compatibilidade, aderir ao semver agrega pouco valor.

Dito isso, eu prefiro muito mais essa construção porque comunica mais claramente aos desenvolvedores que haverá alterações que quebram a compatibilidade. O esquema YYYY.N não me diz nada como desenvolvedor, e nada como administrador.

Então a questão é, o que você quer comunicar com a versão? Se você quer fazer 6 lançamentos de recursos (que podem ou não quebrar a compatibilidade), e a cada 6º lançamento será mais longo suportado com correções; e você não quer versionar lançamentos de correções. Então X.Y é um esquema adequado onde Y=0 é o mais longo suportado. X seria apenas um número. O problema é quando X é o ano, então Y é rapidamente associado a um mês. Então lançamentos mais novos e mais longamente suportados serão lançados em janeiro? Eu sempre tenho que procurar qual versão do Ubuntu é uma LTS, o que me incomoda.

Então, e se o Discourse simplesmente continuar com a versão principal atual. A próxima versão mais longa suportada é chamada 4.0; e então teremos 4.1 a 4.5 como lançamentos de recursos; seguidos por 5.0 que é o mais novo e mais longo suportado.

Então você também não terá aquele momento estranho em que um lançamento é atrasado por causa de um problema importante.

Você pode opcionalmente adicionar um número de “correção” se planeja lançar correções explicitamente (em vez de ter correções contínuas). “Mas então você terá x.y.z que é semver”. Bem, não, parece semver, mas não é. Cada nova versão “menor” pode quebrar a compatibilidade. Então eu sugiro apenas aderir ao esquema X.Y como esquema de versão com Y=0 → LTS.

Deixando a string de versão de lado. Eu gosto do novo plano de lançamento.

4 curtidas
35

Sim, é aqui que as coisas efetivamente estão hoje, especialmente com o sistema flexível de temas.

Então, acho que você está certíssimo aqui:

Isso também significa que a parte “principal” do nosso número de versão atual comunica muito pouco.

Então, pareceu que “ei, poderíamos usar um ano lá para comunicar algo”.

:rocket:

4 curtidas
36

Esta discussão não parece boa. Vejo uma decisão da equipe de desenvolvimento de adotar um novo sistema de versionamento que faz sentido para eles, e outros que de repente parecem considerar que a versão do Discourse estava seguindo o versionamento semântico… o que não estava. Sempre foi um lançamento contínuo (rolling release), pelo menos desde a versão 1.0, ou?

Mas os argumentos de todos os lados do debate parecem falhos:

  • “Padrão da indústria”: O Linux usa versões pares para estáveis e ímpares para desenvolvimento.
  • “A Terra orbita o Sol”: Bem, se você se converter ao Islamismo, terá problemas porque abandonará as versões e não, não corresponderá mais à revolução do Sol, mas aos ciclos da Lua. Aqui, você agora entende que, ao escolher o esquema de versionamento YYYY.Y.Z em vez de X.Y.Z, você impôs uma cultura dominante.
  • Lançamento menor continua incerto: você menciona “assumindo uma cadência mensal”, mas pode ser de 3 semanas ou 7, dependendo da funcionalidade, caso em que contar Y a partir de 0 faz sentido, ou você está realmente visando lançar mensalmente, caso em que contar M a partir de 1 faria mais sentido?

A principal mudança que vejo é que, ao adotar um ritmo mensal, a equipe do Discourse está definindo expectativas e se afastando de metas de lançamento, abraçando lançamentos regulares em vez disso.

LTS por 8 meses não soa realmente como “longo”. O NodeJS está se movendo muito rápido, mas eles mantêm o suporte LTS por mais de 30 meses e algumas versões atuais ao mesmo tempo, enquanto o Ubuntu mantém LTS por anos. Embora eu entenda que o Discourse não é nem uma linguagem nem um sistema operacional, parece anunciar que novas funcionalidades serão lançadas em um ritmo bastante rápido, o que traz outra questão à mente: como novas configurações de administrador são introduzidas de tempos em tempos, logo entraremos no inferno do Wordpress com opções infinitas e complicação incompreensível para administração de sites, também conhecido como bloatware: torna-se importante então esclarecer como você passa de lançamentos existentes com metas para lançamentos regulares, e como você escolhe quais metas abandonar (ou adiar) para um lançamento, etc. (o que pode já estar documentado, mas eu perdi essa parte.)

Você seria tão gentil de compartilhar sua lógica entre o ritmo de desenvolvimento/versionamento e o que você tem em mente para evitar que os administradores se afoguem em muitas configurações e uma curva de aprendizado acentuada?

:heart: :discourse:

1 curtida
37

Antes de responder às suas outras perguntas, quero primeiro esclarecer que nossa frequência de lançamento pretendida não está mudando com esta proposta.

  • Nos últimos 3 anos, fizemos lançamentos “estáveis” aproximadamente a cada 6 meses, visando esses lançamentos para o final de janeiro e julho de cada ano, com pequenas variações:
  • Nos últimos ~8 meses, fizemos lançamentos “beta” aproximadamente a cada mês, além de alguns lançamentos de segurança fora de banda:

Nesta nova proposta, pretendemos manter a mesma cadência que temos seguido, com as principais mudanças sendo:

  • O que agora chamamos de lançamentos “estáveis”, passaremos a chamar de “lançamentos de suporte estendido”
    • Escolhemos esse nome e não “suporte de longo prazo”, porque concordamos que é estendido em relação aos nossos outros lançamentos suportados, mas não necessariamente “de longo prazo”. Esta proposta não inclui a adição de um lançamento de suporte de longo prazo.
    • Atualmente, o suporte para um lançamento estável termina imediatamente quando o próximo lançamento é feito. Com esta nova proposta, o suporte se sobrepõe por ~2 meses, para que as pessoas tenham tempo de atualizar enquanto recebem patches de segurança.
  • O que agora chamamos de lançamentos “beta”, passaremos a chamar de “lançamentos”
    • Atualmente, não damos suporte a lançamentos beta após a data de lançamento. Eles são meramente pontos de verificação ao longo do caminho que vêm com uma notificação para avançar rapidamente, pois também costumam incluir correções de segurança.
    • Com esta proposta, pretendemos dar suporte aos lançamentos por ~2 meses, para que as pessoas possam decidir quando atualizar, enquanto continuam a receber patches de segurança.

Com isso em mente, você sente que suas outras perguntas sobre muitas configurações ainda estão relacionadas a esta proposta? Ou são preocupações independentes que seriam melhor discutidas em um tópico separado?

11 curtidas
38

Obrigado pela sua explicação detalhada @mcwumbly!

De fato, esta é uma preocupação diferente. Personalizar o admin usando um plugin seria útil para fazer testes sobre como isso poderia parecer. Há algum trabalho em andamento em relação a essa abordagem?

2 curtidas
39

Não especificamente isso, mas temos investido bastante na melhoria da interface do admin no último ano. Se você quiser se aprofundar mais nessas questões, pode iniciar um novo tópico e apresentar alguns dos problemas e/ou ideias que gostaria de discutir mais?

3 curtidas
40

Esta é uma ótima mudança (gosto especialmente de ESRs sobrepostos)

Feedback:

  1. Gostaria de ver esse gráfico de ciclo de vida em uma página centralizada para que eu possa verificá-lo facilmente, idealmente com uma tabela de EOL para que eu possa dizer facilmente o que está dentro e fora de suporte a qualquer momento e planejar de acordo (pelo menos para ESRs).

  2. Troca de streams:

Isso seria ótimo – mas mesmo apenas poder escolher qual tag durante a configuração seria enorme. Ou até mesmo incluir as etapas manuais na documentação de configuração. Se alguém quiser começar no estável/ESR, não está nada claro como fazer isso agora para um novo administrador. (Acho que a resposta é passar –skip-rebuild para ./launcher, depois editar a versão e, em seguida, reconstruir pela primeira vez, mas não tenho certeza.) Como, de outra forma, a configuração simplesmente inicia imediatamente a busca e execução da versão mais recente, e voltar atrás é pedir problemas.

(Exemplo da dificuldade para um novo administrador: Atualmente, o resultado de pesquisa nº 1 para “instalar discourse estável” direciona para este tópico, que vincula a outro tópico que explica como atualizar para o estável, mas não como instalar o estável do zero.)

2 curtidas
42

Hoje demos mais um passo em direção à implementação deste RFC - a versão mais recente do Discourse está numerada como v2025.11.0 :tada:

6 curtidas