Está sendo considerada a possibilidade de alterar a numeração e método de geração de releases do Servidor X.Org

Adam Jackson, responsável por vários lançamentos anteriores do X.Org Server, sugerido no seu relatório na conferência XDC2019 mudar para um novo esquema de numeração de problemas. Para ver com mais clareza há quanto tempo um determinado lançamento foi publicado, por analogia com Mesa, foi proposto refletir o ano no primeiro número da versão. O segundo número indicará o número de série do lançamento significativo para o ano em questão, e o terceiro número refletirá as atualizações corretivas.

Além disso, como os lançamentos do X.Org Server são agora bastante raros (o X.Org Server 1.20 foi lançado há um ano e meio) e até agora não visível atividade na formação do X.Org Server 1.21, embora algumas correções e inovações tenham se acumulado no código, propõe-se passar para um modelo planejado para a formação de novos lançamentos.

A proposta se resume ao fato de que a base de código será constantemente desenvolvida por meio de um sistema de integração contínua, e o lançamento será um simples instantâneo do estado em determinadas datas pré-agendadas, desde que todos os testes de CI sejam aprovados com sucesso.
Lançamentos significativos, incluindo novos recursos, estão planejados para serem lançados uma vez a cada 6 meses. À medida que novos recursos são adicionados, também é proposta a criação de compilações intermediárias que possam ramificar automaticamente, por exemplo, uma vez a cada duas semanas.

Hans de Goede, desenvolvedor Fedora Linux na Red Hat, anotadoque o método proposto tem suas desvantagens - como o X.Org Server é muito dependente de hardware, não será possível detectar todos os problemas através de um sistema de integração contínua. Portanto, propõe-se introduzir adicionalmente um sistema de erros de bloqueio de lançamento, cuja presença atrasará o lançamento automático, bem como organizar a formação de lançamentos preliminares para teste antes do lançamento. Michael Dänzer, desenvolvedor Mesa da Red Hat, anotadoque o método proposto é bom para instantâneos e candidatos a lançamento, mas não para versões estáveis ​​finais, inclusive devido à possibilidade de obter uma violação de compatibilidade de ABI em uma versão provisória.

Fonte: opennet.ru

Adicionar um comentário