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:
Milestone | Data 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/ : | 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/ : | 29 de julho de 2016 |
A compilação da fase RC1 é iniciada: | 29 de julho de 2016 |
descongelamento da branch stable/ : | 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 |
Itens marcados com "[*]" identificam passos executados apenas "conforme necessário".
O pré congelamento da árvore doc
é coordenado pela Equipe de Engenharia de Documentação do FreeBSD.
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.
A árvore doc
é recebe a tag da Equipe de Engenharia de Documentação do FreeBSD.
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
.
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
.
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.
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/
. Este arquivo é continuamente atualizado conforme o ciclo progride.12.0
R/schedule.xml
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/
. substituindo 12.0
R/schedule.xmlIGNORE
por INCLUDE
.
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>.