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.0
R/Makefile.hardware_BRANCH
para BETA
, X
RC
ou X
RELEASE
, 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:mergeinfo
releng/
12.0
/%
svn commit
releng/
12.0
/%
svn commit
stable/
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>.