LibreOffice: Plano de lançamentos
TDF LibreOffice Brasil Document Liberation Project Community Blogs Traduções Nextcloud Redmine Perguntas e respostas Doar
Introduction
O encadeamento de lançamentos baseados em tempo tem mostrado ser a alternativa para se produzir software livre com uma melhor qualidade. Lançamentos baseado em tempo é uma forma que não espera por funcionalidades ou correções de falhas, mas é baseada (como o mais puramente possível) no tempo. Isso impõe disciplina na introdução de correções, dá previsibilidade, e permite liberações mais regulares. É também o caso que nós necessariamente lançaremos mais cedo e, em seguida, de forma incremental lançaremos rapidamente correção de falha com base na versão estável anterior. Assim, se você tiver uma necessidade de versões com mais alta qualidade, pode fazer sentido adiar a atualização até a liberação da primeira, ou talvez segunda versão menor.
- LibreOffice has bi-annual, predictable releases that are synchronized with other Free Software projects (e.g. Gnome) and are at least one month ahead of major Linux distribution releases.
- Synchronising the time-based release schedule with the wider Free Software ecosystem also has huge benefits in getting our new features out to users as quickly as possible, with a minimum of lag in the distribution cycle. As a result, we are aiming for six monthly releases, in February and August.
- There are two versions available: the latest release for technology enthusiasts, early adopters and power users, and the previous release - with fewer features but tested for longer - for corporate implementations and more cautious users.
- As a result, users get a new major release every six months with a wide range of features, fixes and enhancements. They will also receive many bug-fixing micro releases. The first X.Y.0 release is intended for early adopters. More conservative users are advised to wait for a later X.Y.3/X.Y.4 bugfix release.
Note that the dates in this schedule may change if there are serious technical or other problems with the release. An extra RC might be needed if the final release candidate has a catastrophic problem. Such a problem could delay the final release by a week or more. The decision should be made at a meeting of the Engineering Steering Committee.
The simplified graphic below shows three releases placed on a timeline consisting of 24 months.
24.2 release
| Release | Freeze | Publishing |
|---|---|---|
| 24.2.0 (freeze: week 02) | Week 47 , 20/11/2023 - 26/11/2023 | Week 05 , 29/1/2024 - 4/2/2024 |
| 24.2.1 | Week 06 , 5/2/2024 - 11/2/2024 | Week 09 , 26/2/2024 - 3/3/2024 |
| 24.2.2 | Week 10 , 4/3/2024 - 10/3/2024 | Week 13 , 25/3/2024 - 31/3/2024 |
| 24.2.3 | Week 15 , 8/4/2024 - 14/4/2024 | Week 18 , 29/4/2024 - 5/5/2024 |
| 24.2.4 | Week 20 , 13/5/2024 - 19/5/2024 | Week 23 , 3/6/2024 - 9/6/2024 |
| 24.2.5 | Week 26 , 24/6/2024 - 30/6/2024 | Week 29 , 15/7/2024 - 21/7/2024 |
| 24.2.6 | Week 33 , 12/8/2024 - 18/8/2024 | Week 36 , 2/9/2024 - 8/9/2024 |
| 24.2.7 | Week 41 , 7/10/2024 - 13/10/2024 | Week 44 , 28/10/2024 - 3/11/2024 |
| End of Life | November 30, 2024 | |
See also the detailed schedule and the release notes.
7.6 release
| Release | Freeze | Publishing |
|---|---|---|
| 7.6.0 (freeze: week 30) | Week 19 , 8/5/2023 - 14/5/2023 | Week 34 , 21/8/2023 - 27/8/2023 |
| 7.6.1 | Week 34 , 21/8/2023 - 27/8/2023 | Week 37 , 11/9/2023 - 17/9/2023 |
| 7.6.2 | Week 38 , 18/9/2023 - 24/9/2023 | Week 39 , 25/9/2023 - 1/10/2023 |
| 7.6.3 | Week 44 , 30/10/2023 - 5/11/2023 | Week 47 , 20/11/2023 - 26/11/2023 |
| 7.6.4 | Week 50 , 11/12/2023 - 17/12/2023 | Week 53 , 1/1/2024 - 7/1/2024 |
| 7.6.5 | Week 05 , 29/1/2024 - 4/2/2024 | Week 08 , 19/2/2024 - 25/2/2024 |
| 7.6.6 | Week 10 , 4/3/2024 - 10/3/2024 | Week 13 , 25/3/2024 - 31/3/2024 |
| 7.6.7 | Week 16 , 15/4/2024 - 21/4/2024 | Week 19 , 6/5/2024 - 12/5/2024 |
| End of Life | June 12, 2024 | |
See also the detailed schedule and the release notes.
7.5 release
| Release | Freeze | Publishing |
|---|---|---|
| 7.5.0 (freeze: week 02) | Week 47 , 21/11/2022 - 27/11/2022 | Week 05 , 30/1/2023 - 5/2/2023 |
| 7.5.1 | Week 06 , 6/2/2023 - 12/2/2023 | Week 09 , 27/2/2023 - 5/3/2023 |
| 7.5.2 | Week 10 , 6/3/2023 - 12/3/2023 | Week 13 , 27/3/2023 - 2/4/2023 |
| 7.5.3 | Week 15 , 10/4/2023 - 16/4/2023 | Week 18 , 1/5/2023 - 7/5/2023 |
| 7.5.4 | Week 20 , 15/5/2023 - 21/5/2023 | Week 23 , 5/6/2023 - 11/6/2023 |
| 7.5.5 | Week 26 , 26/6/2023 - 2/7/2023 | Week 29 , 17/7/2023 - 23/7/2023 |
| 7.5.6 | Week 33 , 14/8/2023 - 20/8/2023 | Week 36 , 4/9/2023 - 10/9/2023 |
| 7.5.7 | Week 38 , 18/9/2023 - 24/9/2023 | Week 39 , 25/9/2023 - 1/10/2023 |
| 7.5.8 | Week 41 , 9/10/2023 - 15/10/2023 | Week 44 , 30/10/2023 - 5/11/2023 |
| End of Life | November 30, 2023 | |
See also the detailed schedule and the release notes.
Datas
O tempo de lançamento é aproximado mas a agenda define a semana do ano no lugar do dia exato. É porque primamos pela flexibilidade. O lançamento pode ser adiado por alguns dias devido a erros impeditivos, problemas na compilação e outras questões técnicas.
O lançamento é composto de várias versões betas e candidatas. São necessárias diversas ações para cada compilação. O fluxo de trabalho ideal tem se mostrado assim:
- Segunda-feira - a data limite de submissão; um lembrete é enviado para a lista de regionalização (internacionalização l10n) dos desenvolvedores, antes do processo ser iniciado
- Terça-feira - o marco é criado sob uma submissão a qual é compilada, permitindo testes de unidade, subsequentes, e testes de rejeição; o marco é anunciado nas listas de discussão de desenvolvedores e de testadores de garantia da qualidade (QA).
- Quarta-feira - as compilações são enviadas para a página inicial de pré-lançamento; elas são anunciadas nas listas de discussão de desenvolvedores e de testadores de garantia da qualidade (QA).
- Quinta-feira - as compilações são enviadas aos servidores da internet
- Sexta-feira - as compilações ficam disponíveis na página oficial de pré-lançamento; elas são anunciadas através de muitos canais, por exemplo, listas de discussão, twitter entre outros
A versão final costuma ser anunciada na quarta-feira, poucos dias após a versão candidata final estiver disponível.
Observe que nós somos muito rigorosos com a versão candidata final, por isso a regressão completa não é necessária. Quando a versão candidata passa nos exames necessários ela é usada como a versão definitiva. E finalmente é apenas renomeada nos servidores.
Cronograma
O cronograma é baseado nas seguintes regras:
- Fazer um lançamento secundário a cada 6 meses e sincronizar com as principais distribuições Linux. Ele sempre vem com uma vasta gama de funcionalidades, correções e melhorias.
- Consertar as falhas a cada mês após o lançamento principal até que fique bom o suficiente para os usuários mais conservadores; diminuir a frequência depois.
- Não coincidir datas finais para a liberação, se possível.
- Oferecer suporte a um lançamento por pelo menos 1 ano.
O resultado é o seguinte gabarito:
| evento | inverno | verão |
|---|---|---|
| x.y congelamento | junho(i) | dezembro(i) |
| x.y.0 lançamento da 1ª versão | agosto(i) | fevereiro(i) |
| x.y.1 lançamento de versão corrigida | setembro(i) | março(i) |
| x.y.2 lançamento de versão corrigida | outubro(i) | abril(i) |
| x.y.3 lançamento de versão corrigida | novembro(i) | maio(i) |
| x.y.4 lançamento de versão corrigida | dezembro(i) | junho(i) |
| x.y.5 lançamento de versão corrigida | fevereiro(m) | agosto(m) |
| x.y.6 lançamento de versão corrigida | abril(m) | outubro(m) |
onde (i) significa início do mês e (m) significa meados do mês.
String freeze
The release plans for the first version of each major release indicate a "hard English string & UI freeze". The idea is to make the lives of translators easier. The translators should be able to trust that no new translatable strings are added into the UI or Help files between the period of the string freeze and release.
In practice, you should keep an eye on the tagging of the first release candidate. One way to find out, if RC1 has been tagged is to visit the tag view of the LibreOffice core repository in Gerrit and input into the filter field: libreoffice-X.Y.Z. If the results do not contain any entry for libreoffice-X.Y.Z.1, RC1 has not yet been tagged and string changes can still be committed.
After the first version of a major release is out, correcting mistakes in the UI and Help strings is fine. Any completely new content should target the next major release.
Esquema da versão
Fazemos diversas compilações para cada lançamento. O seguinte esquema de versão é usado:
- X.Y.0.0.alphaN - n-ésima versão alfa da distribuição inicial
- X.Y.0.0.betaN - n-ésima versão beta da distribuição inicial
- X.Y.0.N - n-ésima versão candidata da distribuição inicial, sendo que a última RC é considerada como final e disponibilizada na página principal para distribuição
- X.Y.1.N - n-ésima versão candidata da 1ª distribuição corrigida, sendo que a última RC é considerada como final e disponibilizada na página principal para distribuição
Parece ser o melhor compromisso com as seguintes vantagens:
- de fácil compreensão para usuários normais, alfa e beta, de modo a definir expectativas razoáveis
- classificação alfabética correta em RPM na página de informações de erros (bugzilla)
- “fácil” para analisar (alfa e beta são delimitadas pelo ponto)
Houve um longo debate sobre este esquema na lista de discussão.
Acelerar o ciclo de lançamento
Esta aceleração do ciclo de lançamento envolve algumas considerações na engenharia de lançamento e esforços de controle de qualidade (QA). Para reduzir o custo destes, iremos, ao longo do tempo, trabalhar para fornecer dados completos, ou seja, contendo todos os idiomas, com instantâneos diários do ramo principal para permitir o teste contínuo de melhorias do código.
Da mesma forma, pretendemos cada vez mais automatizar o processo de compilação para permitir um fluxo de liberação muito menor, e que continue a diminuir a pegada dos nossos binários para permitir a transferência muito mais rápida das construções do produto equivalente.
Versões com o suporte encerrado
Geralmente um ramo de distribuição tem um tempo de vida de aproximadamente nove meses. O término do suporte (EOL) chega um mês após o último lançamento planejado.
Entretanto, se você quer um período maior para o suporte, sinta-se convidado a contratar os serviços de qualquer desenvolvedor certificado nível L3.
Because of the amount of data, the releases were split out to ReleasePlan/Archive.