LibreOffice: Plano de lançamentos

From The Document Foundation Wiki
Jump to: navigation, search
This page is a translated version of the page ReleasePlan and the translation is 79% complete.

Other languages:
العربية • ‎dansk • ‎Deutsch • ‎English • ‎español • ‎français • ‎Bahasa Indonesia • ‎italiano • ‎日本語 • ‎português do Brasil • ‎română • ‎русский • ‎中文(简体)‎

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.
  • Time-based release trains have been shown to produce the best quality Free software. A time based release is one that does not wait for either features, or bug fixes - but is based (as purely as possible) on time. This enforces discipline in introducing fixes, gives predictability, and allows more regular releasing. It is also the case that we will necessarily release earlier, and then rapidly, incrementally bug fix releases based on the previous stable version. Thus if you have a need for the very highest quality version, it can make sense to defer a move until the first or perhaps second minor point release.
  • 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 does not fit the Release Criteria. Such problem would shift the final release by one week or even more. Template:LibOReleaseLifecycle/pt-br

7.0 release

datas referenciais para a distribuição e correção de falhas
Lançamento Congelamento Publicação
7.0.0 (freeze: week 29) Week 19 , 4/5/2020 - 10/5/2020 Week 32 , 3/8/2020 - 9/8/2020
7.0.1 Week 33 , 10/8/2020 - 16/8/2020 Week 36 , 31/8/2020 - 6/9/2020
7.0.2 Week 38 , 14/9/2020 - 20/9/2020 Week 41 , 5/10/2020 - 11/10/2020
7.0.3 Week 43 , 19/10/2020 - 25/10/2020 Week 46 , 9/11/2020 - 15/11/2020
7.0.4 Week 48 , 23/11/2020 - 29/11/2020 Week 51 , 14/12/2020 - 20/12/2020
7.0.5 Week 06 , 8/2/2021 - 14/2/2021 Week 09 , 1/3/2021 - 7/3/2021
7.0.6 Week 15 , 12/4/2021 - 18/4/2021 Week 18 , 3/5/2021 - 9/5/2021
Término do suporte May 31, 2021

Leia também o cronograma detalhado e as notas do lançamento.

6.4 release

datas referenciais para a distribuição e correção de falhas
Lançamento Congelamento Publicação
6.4.0 (freeze: week 02) Week 42 , 14/10/2019 - 20/10/2019 Week 05 , 27/1/2020 - 2/2/2020
6.4.1 Week 06 , 3/2/2020 - 9/2/2020 Week 09 , 24/2/2020 - 1/3/2020
6.4.2 Week 09 , 24/2/2020 - 1/3/2020 Week 12 , 16/3/2020 - 22/3/2020
6.4.3 Week 13 , 23/3/2020 - 29/3/2020 Week 16 , 13/4/2020 - 19/4/2020
6.4.4 Week 18 , 27/4/2020 - 3/5/2020 Week 21 , 18/5/2020 - 24/5/2020
6.4.5 Week 24 , 8/6/2020 - 14/6/2020 Week 27 , 29/6/2020 - 5/7/2020
6.4.6 Week 30 , 20/7/2020 - 26/7/2020 Week 33 , 10/8/2020 - 16/8/2020
6.4.7 Week 39 , 21/9/2020 - 27/9/2020 Week 42 , 12/10/2020 - 18/10/2020
Término do suporte November 30, 2020

Leia também o cronograma detalhado e as notas do lançamento.

6.3 release

datas referenciais para a distribuição e correção de falhas
Lançamento Congelamento Publicação
6.3.0 (freeze: week 29) Week 19 , 6/5/2019 - 12/5/2019 Week 32 , 5/8/2019 - 11/8/2019
6.3.1 Week 32 , 5/8/2019 - 11/8/2019 Week 35 , 26/8/2019 - 1/9/2019
6.3.2 Week 36 , 2/9/2019 - 8/9/2019 Week 39 , 23/9/2019 - 29/9/2019
6.3.3 Week 41 , 7/10/2019 - 13/10/2019 Week 44 , 28/10/2019 - 3/11/2019
6.3.4 Week 47 , 18/11/2019 - 24/11/2019 Week 50 , 9/12/2019 - 15/12/2019
6.3.5 Week 05 , 27/1/2020 - 2/2/2020 Week 08 , 17/2/2020 - 23/2/2020
6.3.6 Week 15 , 6/4/2020 - 12/4/2020 Week 18 , 27/4/2020 - 3/5/2020
Término do suporte May 29, 2020

Leia também o cronograma detalhado e as notas do lançamento.

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.

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.