ReleasePlan/pt-br

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.

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

Future Fresh Still

7.4 release
See also the detailed schedule and the release notes.

7.3 release
See also the detailed schedule and the release notes.

7.2 release
See also the detailed schedule and the release notes.

7.1 release
See also the detailed schedule and the release notes.

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

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

6.3 release
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:

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.