LibreOffice: Plano de lançamentos

    From The Document Foundation Wiki
    This page is a translated version of the page ReleasePlan and the translation is 59% complete.

    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 does bi-annual, predictable releases that are in sync with other Free Software projects (eg. Gnome) and are at least one month ahead major Linux distribution releases.
    • Synchronizing time-based release schedule with the wider Free Software ecosystem also has huge advantages, by getting our new features, out to users as quickly as possible – with a minimum of distribution cycle lag. In consequence, we aim at six monthly releases, and over time nudge them to align well with the March/September norms.
    • There are 2 branches: Fresh (the newest release) and Still (the previous release), which are intended for mainstream feature users and conservative, corporate deployments respectively.
    • As a result, users get new major version every six months with a wide range of features, fixes, and enhancements. In addition, they get many pure bugfix 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.Z bugfix release.

    Note that the dates mentioned in the schedule might get shifted 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 issue. Such a problem could shift the final release by one week or more. The decision should be made in a meeting of the Engineering Steering Committee.

    The simplified graphic below shows three releases placed on a timeline consisting of 24 months.

    Future
    Fresh
    Still

    24.2 release

    Basic dates for the initial and bugfix releases
    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

    7.6 release

    Basic dates for the initial and bugfix releases
    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

    Basic dates for the initial and bugfix releases
    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:

    lançamentos intercalados
    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.