Esta seção descreve os procedimentos gerais do ciclo de release do FreeBSD a partir de uma branch stable/.
Na preparação para o code freeze em uma branch stable, vários arquivos precisam ser atualizados para refletir o ciclo de release que está oficialmente em andamento. Esses arquivos são todos relativos ao nível mais alto da branch stable:
| Arquivo para editar | O que mudar |
|---|---|
sys/conf/newvers.sh | Atualize o valor da BRANCH para refletir PRERELEASE |
Makefile.inc1 | Atualize o TARGET_TRIPLE |
lib/clang/llvm.build.mk | Atualize o OS_VERSION |
Makefile.libcompat | Atualize o LIB32CPUFLAGS |
gnu/usr.bin/groff/tmac/mdoc.local.in | Adiciona uma nova entrada .ds para a versão do FreeBSD, e atualiza doc-default-operating-system (FreeBSD 11.x e anteriores apenas) |
No repositório doc, atualize também head/pt_BR.ISO8859-1/htdocs/releases/, alternando o valor de 12.0R/Makefile.hardware_BRANCH para BETA, XRC ou XRELEASE, respectivamente.
Após o code slush, a próxima fase do ciclo de release é o code freeze. Este é o ponto no qual todos os commits para a branch stable requerem aprovação explícita da Equipe de Engenharia de Release do FreeBSD. Isto é reforçado por hooks de pré-commit no repositório Subversion editando base/svnadmin/conf/approvers para incluir uma expressão regular que coincida com a branch stable/ para a release:12/
^/stable/re ^/12/releng/re12.0/
Há duas exceções gerais para exigir aprovação de commit durante o ciclo de release. A primeira é qualquer alteração que precise ser "committed" pelo Engenheiro de Release para continuar com o fluxo de trabalho diário do ciclo de lançamento, e a outra são as correções de segurança que podem ocorrer durante o ciclo de lançamento.
Quando o code freeze estiver em vigor, a próxima construção da branch será rotulada como BETA1. Isso é feito atualizando o valor de BRANCH em sys/conf/newvers.sh de PRERELEASE para BETA1.
Feito isso, o primeiro conjunto de builds BETA é iniciado. Builds BETA subseqüentes não requerem atualizações em nenhum arquivo diferente do sys/conf/newvers.sh, incrementando o número de compilação da versão BETA.
Quando a primeira construção RC (Release Candidate) está pronta para começar, a branch releng/ é criada. Este é um processo de várias etapas que deve ser feito em uma ordem específica, a fim de evitar anomalias, como sobreposições com valores de __ FreeBSD_version, por exemplo. Os caminhos listados abaixo são relativos ao repositório raiz. A ordem dos commits e o que mudar são:
%svn cp ^/stable/12/releng/12.0/
| Arquivo para editar | O que mudar |
|---|---|
releng/ | Altere BETA para RC1 |
releng/ | Atualize o __ FreeBSD_version |
releng/ | Substitua latest por quarterly (trimestral) como a localização padrão do repositório de pacotes |
releng/ | Substitua latest por quarterly (trimestral) como a localização padrão do repositório de pacotes |
stable/ | Atualize BETA para PRERELEASE |
stable/ | Atualize o __ FreeBSD_version |
svnadmin/conf/approvers | Adicione uma nova linha de aprovadores para a branch releng como foi feito para a branch stable |
%svn propdel -R svn:mergeinforeleng/12.0/%svn commitreleng/12.0/%svn commitstable/12/
Agora que existem dois novos valores de __ FreeBSD_version, também atualize head/pt_BR.ISO8859-1/books/porters-handbook/versions/chapter.xml no repositório do Projeto de Documentação.
Depois que a primeira compilação de um RC estiver concluída e testada, a branch stable/ pode ser “descongelada” removendo (ou comentando) a entrada ^/stable/ em 12/svnadmin/conf/approvers.
Seguindo a disponibilidade do primeiro RC, o Time Bugmeister do FreeBSD deve ser avisado por e-mail para adicionar o novo FreeBSD -RELEASE às versões disponíveis no menu drop-down exibido no rastreador de bugs.
All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.