2. Informação Geral e Preparativos

Aproximadamente dois meses antes do início do ciclo de vida de uma nova versão, a Equipe de Engenharia de Release do FreeBSD decide sobre um cronograma para o seu lançamento. A programação inclui os vários milestones do ciclo de release, como datas de congelamento, datas para as branches e datas para compilação do código. Por exemplo:

MilestoneData prevista
pré congelamento da head/:27 de maio de 2016
Congelamento da head/:10 de junho de 2016
Congelamento de KBI da head/:24 de junho de 2016
Pré congelamento da árvore doc/ [1]:24 de junho de 2016
Branch trimestral dos ports [2]:1º de julho de 2016
branch stable/12/:8 de julho de 2016
Aplicação da tag na árvore doc/ [3]:8 de julho de 2016
Começa a compilação da fase BETA1:8 de julho de 2016
descongelamento da branch head/:9 de julho de 2016
Começa a compilação da fase BETA2:15 de julho de 2016
Começa a compilação da fase BETA3 [*]:22 de julho de 2016
branch releng/12.0/:29 de julho de 2016
A compilação da fase RC1 é iniciada:29 de julho de 2016
descongelamento da branch stable/12/:30 de julho de 2016
Começa a compilação da fase RC2:5 de agosto de 2016
Última compilação dos ports [4]:6 de agosto de 2016
Aplicação da tag na árvore dos ports:12 de agosto de 2016
compilação da fase RC3 [*]:12 de agosto de 2016
início de compilação da RELEASE:19 de agosto de 2016
Anúncio da RELEASE:2 de setembro de 2016

Nota:

Itens marcados com "[*]" identificam passos executados apenas "conforme necessário".

  1. O pré congelamento da árvore doc é coordenado pela Equipe de Engenharia de Documentação do FreeBSD.

  2. A branch trimestral da árvore da coleção de ports é determinada quando a compilação final da fase RC é planejada. Uma nova branch trimestral é criada no primeiro dia do trimestre, portanto, essa métrica deve ser usada ao considerar os marcos do ciclo de release. Uma branch trimestral é criada pela Equipe de Gerenciamento de Ports do FreeBSD.

  3. A árvore doc é recebe a tag da Equipe de Engenharia de Documentação do FreeBSD.

  4. A compilação final dos pacotes é feita pela Equipe de Gerenciamento de Ports do FreeBSD após a compilação final (ou o que é esperada ser a final) de uma fase RC.

Nota:

Se a versão RELEASE estiver sendo criada a partir de uma branch stable existente, a data de congelamento do KBI poderá ser excluída, já que o KBI já está congelado em branchs stable.

Ao escrever o cronograma do ciclo de versões, várias coisas precisam ser levadas em consideração, em particular os milestones nos quais a data alvo depende de milestones pré-definidos sobre os quais existe uma dependência. Por exemplo, a aplicação da tag de release da Coleção de Ports é originada da branch trimestral ativa no momento da última fase do RC. Isso em parte define qual branch trimestral é usada, quando a aplicação da tag pode acontecer e qual revisão da árvore de ports é usada para a construção final de uma RELEASE.

Depois de um acordo geral sobre o cronograma, a Equipe de Engenharia de Release do FreeBSD envia e-mails para os desenvolvedores do FreeBSD.

É normal que muitos desenvolvedores informem a Equipe de Engenharia de Release do FreeBSD sobre vários trabalhos em andamento. Em alguns casos, uma extensão para o trabalho em andamento será solicitada e, em outros casos, uma solicitação para uma aprovação geral para um subconjunto específico da árvore será feita.

Quando tais solicitações são feitas, é importante certificar-se de que os cronogramas (mesmo que estimados) sejam discutidos. Para as aprovações gerais, o período de tempo para a aprovação geral deve ser claro. Por exemplo, um desenvolvedor do FreeBSD pode solicitar aprovações gerais desde o início do code slush até o início da construção da primeira RC.

Nota:

Para manter o controle das aprovações gerais, a Equipe de Engenharia de Release do FreeBSD usa um repositório interno para manter um registro de tais solicitações, que define a área na qual uma aprovação geral foi concedida, o(s) autor(es), quando a aprovação geral expira e a razão pela qual a aprovação foi concedida. Um exemplo disso é a concessão de uma aprovação geral na release/doc/ a todos os membros da Equipe de Engenharia de Release do FreeBSD até o RC final para atualizar as notas de lançamento e outras documentação relacionada ao lançamento.

Nota:

A Equipe de Engenharia de Release do FreeBSD também usa este repositório para rastrear solicitações de aprovação pendentes que são recebidas antes de iniciar várias compilações durante o ciclo de release, que o Engenheiro de Release especifica o período de corte com um email para os desenvolvedores do FreeBSD.

Dependendo do conjunto de código subjacente em questão, e do impacto geral que o conjunto de código tem no FreeBSD como um todo, tais solicitações podem ser aprovadas ou negadas pela Equipe de Engenharia de Release do FreeBSD.

O mesmo se aplica às extensões de trabalho em andamento. Por exemplo, o trabalho em andamento para um novo driver de dispositivo que de outra forma é isolado do restante da árvore pode receber uma extensão. Um novo scheduler, no entanto, pode não ser viável, especialmente se tais mudanças dramáticas não existirem em outra branch.

O cronograma também é adicionado ao site do projeto, no repositório doc, em head/en_US.ISO8859-1/htdocs/releases/12.0R/schedule.xml. Este arquivo é continuamente atualizado conforme o ciclo progride.

Nota:

Na maioria dos casos, o schedule.xml pode ser copiado de uma versão anterior e atualizado de acordo.

Além de adicionar o schedule.xml ao site, o head/share/xml/navibar.ent e o head/share/xml/release.ent também são atualizados para adicionar o link para o cronograma em várias subpáginas, bem como para habilitar o link para o cronograma na página principal do website do projeto.

O cronograma também chamado a partir de head/en_US.ISO8859-1/htdocs/releng/index.xml.

Aproximadamente um mês antes do code slush, a Equipe de Engenharia de Release do FreeBSD envia um email de lembrete para os desenvolvedores do FreeBSD.

Uma vez que as primeiras compilações do ciclo de release estejam disponíveis, atualize a entidade beta.local.where em head/en_US.ISO8859-1/htdocs/releases/12.0R/schedule.xml. substituindo IGNORE por INCLUDE.

Nota:

Se dois ciclos de lançamento paralelo estão acontecendo ao mesmo tempo, a entidade beta2.local.where pode ser usada no lugar.

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>.