Product SiteDocumentation Site

1.6. Ciclo de vida de um Lançamento

O projeto vai ter simultaneamente de três a seis versões diferentes de cada programa, chamadas Experimental, Instável, Teste, Estável, Estável Antiga e até a Estável Antiga Antiga . Cada uma corresponde a uma fase diferente em desenvolvimento. Para um entendimento claro, vamos dar uma olhada no caminho de um programa, do seu empacotamento inicial à inclusão em uma versão estável do Debian.

1.6.1. O Estado Experimental

Primeiro vamos dar uma olhada no caso particular da distribuição Experimental : este é um grupo de pacotes Debian correspondente ao software atualmente em desenvolvimento, e não necessariamente concluído, explicando o seu nome . Nem tudo passa por esta etapa, alguns desenvolvedores adicionam aqui os pacotes a fim de obter o feedback dos mais experientes (ou mais valentes) usuários.
Por outro lado, essa distribuição frequentemente abriga importantes modificações para pacotes básicos, cuja integração na Instável (Unstable) com erros graves teria repercussões críticas. Portanto, é uma distribuição completamente isolada, com seus pacotes nunca migrando para outra versão (exceto pela intervenção direta e expressa do mantenedor ou dos ftpmasters). Ela também não é auto-suficiente: apenas um subconjunto dos pacotes existentes estão presentes na Experimental, e geralmente não incluem o sistema de base. Esta distribuição é, portanto, útil principalmente em combinação com uma outra distribuição auto-suficiente, como a Instável (Unstable).

1.6.2. O Estado Instável

Let us turn back to the case of a typical package. The maintainer creates an initial package, which they compile for the Unstable version and place on the ftp-master.debian.org server. This first event involves inspection and validation from the ftpmasters. The software is then available in the Unstable distribution, which is the “cutting edge” distribution chosen by users who are more concerned with having up-to-date packages than worried about serious bugs. They discover the program and then test it.
Se encontrarem bugs, reportam para o mantenedor do pacote. O mantenedor então elabora regularmente versões corrigidas que envia (por upload) para o servidor.
Every newly updated package is updated on all Debian mirrors around the world within six hours. The users then test the corrections and search for other problems resulting from the modifications. Several updates may then occur rapidly. During these times, autobuilder robots come into action. Most frequently, the maintainer has only one traditional PC and has compiled their package on the amd64 (or i386) architecture (or they opted for a source-only upload, thus without any precompiled package); the autobuilders take over and automatically compile versions for all the other architectures. Some compilations may fail; the maintainer will then receive a bug report indicating the problem, which is then to be corrected in the next versions. When the bug is discovered by a specialist for the architecture in question, the bug report may come with a patch ready to use.
Compilação de um pacote pelos autobuilders

Figura 1.2. Compilação de um pacote pelos autobuilders

1.6.3. Migração para Teste

Um pouco mais tarde, o pacote terá amadurecido; compilados em todas arquiteturas, não vai ter sofrido modificações recentes. É então um candidato de inscrição na distribuição Teste - um grupo de pacotes instáveis escolhidos de acordo com alguns critérios quantificáveis. Todos os dias um programa seleciona automaticamente os pacotes para incluir em Teste , de acordo com os elementos que garantem um certo nível de qualidade:
  1. carece de bugs críticos, ou, pelo menos, menos do que a versão atualmente incluído no Teste ;
  2. at least 5 days spent in Unstable, which is usually sufficient time to find and report any serious problems (successfully passing the package's own test suite, if it has one, reduces that time);
  3. compilação bem-sucedida em todas arquiteturas suportadas oficialmente;
  4. dependencies that can be satisfied in Testing, or that can at least be moved there together with the package in question;
  5. automatic quality tests of the package (autopkgtest) — if defined — don't show any regression.
É claro que este sistema não é infalível; bugs críticos são encontrados regularmente em pacotes incluídos na Teste . Ainda assim, é geralmente eficaz, Teste apresenta muito menos problemas do que a Instável , sendo para muitos, um bom compromisso entre estabilidade e novidade.

1.6.4. A Promoção de Teste para Estável

Let us suppose that our package is now included in Testing. As long as it has room for improvement, its maintainer must continue to improve it and restart the process from Unstable (but its later inclusion in Testing is generally faster: unless it changed significantly, all of its dependencies are already available). When it reaches perfection, the maintainer has completed their work. The next step is the inclusion in the Stable distribution, which is, in reality, a simple copy of Testing at a moment chosen by the Release Manager. Ideally, this decision is made when the installer is ready, and when no program in Testing has any known critical bugs.
Como esse momento nunca chega verdadeiramente, na prática, o Debian deve se comprometer a: remover pacotes cujo mantenedor não tiver corrigido bugs a tempo, ou concorda em publicar uma distribuição com alguns bugs nos milhares de programas. O Gerente de lançamento vai previamente anunciar um período de congelamento, durante o qual cada atualização para Teste deve ser aprovado. O objetivo aqui é evitar qualquer nova versão (e seus novos bugs), e só aprovar as atualizações com correção de bugs.
Caminho de um pacote através das várias versões Debian

Figura 1.3. Caminho de um pacote através das várias versões Debian

After the release of a new stable version, the Stable Release Managers manage all further development (called “revisions”, ex: 7.1, 7.2, 7.3 for version 7). These updates systematically include all security patches. They will also include the most important corrections (the maintainer of a package must prove the gravity of the problem that they wish to correct in order to have their updates included).
At the end of the journey, our hypothetical package is now included in the stable distribution. This journey, not without its difficulties, explains the significant delays separating the Debian Stable releases. This contributes, over all, to its reputation for quality. Furthermore, the majority of users are satisfied using one of the three distributions simultaneously available. The system administrators, concerned above all about the stability of their servers, don't need the latest and greatest version of GNOME; they can choose Debian Stable, and they will be satisfied. End users, more interested in the latest versions of GNOME or KDE Plasma than in rock-solid stability, will find Debian Testing to be a good compromise between a lack of serious problems and relatively up-to-date software. Finally, developers and more experienced users may blaze the trail, testing all the latest developments in Debian Unstable right out of the gate, at the risk of suffering the headaches and bugs inherent in any new version of a program. To each their own Debian!
Trilha Cronológica de um pacote de programas do Debian

Figura 1.4. Trilha Cronológica de um pacote de programas do Debian

1.6.5. O Status Estável Antiga e Estável Antiga Antiga

Cada lançamento Estável tem uma expectativa de vida de 5 anos e cada lançamento tende a acontecer a cada 2 anos, pode acontecer de haver 3 lançamentos com suporte em dado momento do tempo. Quando um novo lançamento estável acontece, o lançamento anterior se torna Estável Antiga e o anterior a este se torna Estável Antiga Antiga.
Esse Suporte de Longo Prazo (Long Term Support - LTS) dos lançamentos Debiané uma iniciativa recente: contribuintes individuais e companhias juntaram forças para criar a equipe Debian LTS. Lançamentos antigos que não são mais suportados pela equipe de segurança do Debian ficam sob responsabilidade dessa nova equipe.
The Debian security team handles security support in the current Stable release and also in the Oldstable release (but only for as long as is needed to ensure one year of overlap with the current stable release). This amounts roughly to three years of support for each release. The Debian LTS team handles the last (two) years of security support so that each releases benefits from at least 5 years of support and so that users can upgrade from version N to N+2, for example from Debian 8 "Jessie" to Debian 10 "Buster".