aboutsummaryrefslogtreecommitdiff
path: root/pt_BR.ISO8859-1/articles/freebsd-releng/article.xml
blob: 863005a38be0734c89b7f559f3242e3531ba7301 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN" "http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd" [
<!-- local entities --><!ENTITY team.bugmeister "&os; Bugmeister Team">
<!ENTITY team.doceng "&os; Documentation Engineering Team">
<!ENTITY team.portmgr "&os; Ports Management Team">
<!ENTITY team.postmaster "&os; Postmaster Team">
<!ENTITY team.re "&os; Release Engineering Team">
<!ENTITY team.secteam "&os; Security Team">
<!ENTITY branch.head "<literal xmlns='http://docbook.org/ns/docbook'>head/</literal>">
<!ENTITY branch.stable "<literal xmlns='http://docbook.org/ns/docbook'>stable/</literal>">
<!ENTITY branch.stablex "<literal xmlns='http://docbook.org/ns/docbook'>stable/<replaceable>12</replaceable>/</literal>">
<!ENTITY branch.releng "<literal xmlns='http://docbook.org/ns/docbook'>releng/</literal>">
<!ENTITY branch.relengx "<literal xmlns='http://docbook.org/ns/docbook'>releng/<replaceable>12.0</replaceable>/</literal>">
<!ENTITY branch.releasex "<literal xmlns='http://docbook.org/ns/docbook'>release/<replaceable>12.0.0</replaceable>/</literal>">
<!ENTITY branch.revision "<replaceable xmlns='http://docbook.org/ns/docbook'>12.0</replaceable>">
<!-- Externally included files --><!ENTITY release.building SYSTEM "./releng-building.xml">
<!ENTITY release.major.version SYSTEM "./releng-major-version.xml">
<!ENTITY release.minor.version SYSTEM "./releng-minor-version.xml">
<!ENTITY release.mirrors SYSTEM "./releng-mirrors.xml">
<!ENTITY release.terminology SYSTEM "./releng-terminology.xml">
<!ENTITY release.website SYSTEM "./releng-website.xml">
]>
<article xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:its="http://www.w3.org/2005/11/its" version="5.0" xml:lang="pt_BR">

  <info>
    <title>Engenharia de Release do FreeBSD</title>

    <authorgroup>
      <author><personname> <firstname>Glen</firstname> <surname>Barber</surname> </personname> <affiliation> <orgname class="nonprofit"> <link xlink:href="https://www.freebsdfoundation.org">The FreeBSD Foundation</link></orgname> </affiliation> <affiliation> <orgname> <link xlink:href="https://www.netgate.com">Rubicon Communications, LLC (Netgate)</link></orgname> <address><email>gjb@FreeBSD.org</email></address> </affiliation></author>
    </authorgroup>

    <legalnotice xml:id="trademarks" role="trademarks">
      <para>FreeBSD is a registered trademark of the FreeBSD Foundation.</para>
      <para>Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium, Pentium, and Xeon are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.</para>
      <para>Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the <quote></quote> or the <quote>®</quote> symbol.</para>
    </legalnotice>

    <pubdate>$FreeBSD$</pubdate>

    <abstract>
      <para>Este artigo descreve o processo por trás do modelo de engenharia de release adotado pelo Projeto FreeBSD.</para>
    </abstract>
  </info>

  <sect1 xml:id="introduction">
    <title>Introdução ao Processo de Engenharia de Release do FreeBSD</title>

    <para>O desenvolvimento do FreeBSD segue um fluxo muito específico. Em geral, todas as mudanças no sistema base do FreeBSD são feitas em uma branch chamada <literal>head/</literal>, a qual reflete o topo da árvore de código fonte.</para>

    <para>Após um período razoável de testes, as alterações podem ser fundidas na branch <literal>stable/</literal>. O período de tempo mínimo padrão antes da fusão das alterações na branch <literal>stable/</literal> é de três (3) dias.</para>

    <para>Embora seja uma regra geral esperar pelo menos três (3) dias antes de fundir o código produzido na branch <literal>head/</literal>, existem algumas circunstâncias especiais em que uma fusão imediata pode ser necessária, tal como uma correção de segurança crítica ou uma correção de bug que inibe diretamente o processo de compilação  de uma release.</para>

    <para>Após vários meses, quando o número de mudanças na branch <literal>stable/</literal> cresceu significativamente, é hora de lançar a próxima versão do FreeBSD. Essas versões foram historicamente chamadas de <quote>point</quote> releases.</para>

    <para>Entre as versões das branches <literal>stable/</literal>, aproximadamente a cada dois (2) anos, uma nova versão é criada vinda diretamente da branch <literal>head/</literal>. Essas versões foram historicamente chamadas de versões <quote>dot-zero</quote>.</para>

    <para>Este artigo irá destacar o fluxo de trabalho e as responsabilidades da Equipe de Engenharia de Release do FreeBSD para ambas as versões <quote>dot-zero</quote> e <quote>point release</quote>.</para>

    <para>As seções a seguir deste artigo descrevem:</para>

    <variablelist>
      <varlistentry>
	<term><xref linkend="releng-prep"/></term>

	<listitem>
	  <para>Informações gerais e preparativos antes de iniciar o ciclo de release.</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><xref linkend="releng-website"/></term>

	<listitem>
	  <para>Alterações na Página Web Durante o Ciclo de Release</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><xref linkend="releng-terms"/></term>

	<listitem>
	  <para>Terminologia e informações gerais, como <quote>code slush</quote> e <quote>code freeze</quote>, usadas por todo este documento.</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><xref linkend="releng-head"/></term>

	<listitem>
	  <para>O processo de Engenharia de Release para uma versão <quote>dot-zero</quote>.</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><xref linkend="releng-stable"/></term>

	<listitem>
	  <para>O processo de Engenharia de Release para uma versão <quote>point release</quote>.</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><xref linkend="releng-building"/></term>

	<listitem>
	  <para>Informações relacionadas aos procedimentos específicos para construir o meio de instalação.</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><xref linkend="releng-mirrors"/></term>

	<listitem>
	  <para>Procedimentos para publicar um meio de instalação.</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><xref linkend="releng-wrapup"/></term>

	<listitem>
	  <para>Encerrando o ciclo de release.</para>
	</listitem>
      </varlistentry>
    </variablelist>
  </sect1>

  <sect1 xml:id="releng-prep">
    <title>Informação Geral e Preparativos</title>

    <para>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:</para>

    <informaltable frame="none" pgwide="0">
      <tgroup cols="2">
	<thead>
	  <row>
	    <entry>Milestone</entry>
	    <entry>Data prevista</entry>
	  </row>
	</thead>

	<tbody>
	  <row>
	    <entry>pré congelamento da <literal>head/</literal>:</entry>
	    <entry>27 de maio de 2016</entry>
	  </row>

	  <row>
	    <entry>Congelamento da <literal>head/</literal>:</entry>
	    <entry>10 de junho de 2016</entry>
	  </row>

	  <row>
	    <entry>Congelamento de KBI da <literal>head/</literal>:</entry>
	    <entry>24 de junho de 2016</entry>
	  </row>

	  <row>
	    <entry>Pré congelamento da árvore <literal>doc/</literal> [1]:</entry>
	    <entry>24 de junho de 2016</entry>
	  </row>

	  <row>
	    <entry>Branch trimestral dos ports [2]:</entry>
	    <entry>1º de julho de 2016</entry>
	  </row>

	  <row>
	    <entry>branch <literal>stable/<replaceable>12</replaceable>/</literal>:</entry>
	    <entry>8 de julho de 2016</entry>
	  </row>

	  <row>
	    <entry>Aplicação da tag na árvore <literal>doc/</literal> [3]:</entry>
	    <entry>8 de julho de 2016</entry>
	  </row>

	  <row>
	    <entry>Começa a compilação da fase BETA1:</entry>
	    <entry>8 de julho de 2016</entry>
	  </row>

	  <row>
	    <entry>descongelamento da branch <literal>head/</literal>:</entry>
	    <entry>9 de julho de 2016</entry>
	  </row>

	  <row>
	    <entry>Começa a compilação da fase BETA2:</entry>
	    <entry>15 de julho de 2016</entry>
	  </row>

	  <row>
	    <entry>Começa a compilação da fase BETA3 [*]:</entry>
	    <entry>22 de julho de 2016</entry>
	  </row>

	  <row>
	    <entry>branch <literal>releng/<replaceable>12.0</replaceable>/</literal>:</entry>
	    <entry>29 de julho de 2016</entry>
	  </row>

	  <row>
	    <entry>A compilação da fase RC1 é iniciada:</entry>
	    <entry>29 de julho de 2016</entry>
	  </row>

	  <row>
	    <entry>descongelamento da branch <literal>stable/<replaceable>12</replaceable>/</literal>:</entry>
	    <entry>30 de julho de 2016</entry>
	  </row>

	  <row>
	    <entry>Começa a compilação da fase RC2:</entry>
	    <entry>5 de agosto de 2016</entry>
	  </row>

	  <row>
	    <entry>Última compilação dos ports [4]:</entry>
	    <entry>6 de agosto de 2016</entry>
	  </row>

	  <row>
	    <entry>Aplicação da tag na árvore dos ports:</entry>
	    <entry>12 de agosto de 2016</entry>
	  </row>

	  <row>
	    <entry>compilação da fase RC3 [*]:</entry>
	    <entry>12 de agosto de 2016</entry>
	  </row>

	  <row>
	    <entry>início de compilação da RELEASE:</entry>
	    <entry>19 de agosto de 2016</entry>
	  </row>

	  <row>
	    <entry>Anúncio da RELEASE:</entry>
	    <entry>2 de setembro de 2016</entry>
	  </row>
	</tbody>
      </tgroup>
    </informaltable>

    <note>
      <para>Itens marcados com "[*]" identificam passos executados apenas "conforme necessário".</para>
    </note>

    <orderedlist>
      <listitem>
	<para>O pré congelamento da árvore <literal>doc</literal> é coordenado pela Equipe de Engenharia de Documentação do FreeBSD.</para>
      </listitem>

      <listitem>
	<para>A branch trimestral da árvore da coleção de ports é determinada quando a compilação final da fase <literal>RC</literal> é 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.</para>
      </listitem>

      <listitem>
	<para>A árvore <literal>doc</literal> é recebe a tag da Equipe de Engenharia de Documentação do FreeBSD.</para>
      </listitem>

      <listitem>
	<para>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 <literal>RC</literal>.</para>
      </listitem>
    </orderedlist>

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

    <para>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 <literal>RC</literal>. 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 <literal>RELEASE</literal>.</para>

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

    <para>É 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 <quote>aprovação geral</quote> para um subconjunto específico da árvore será feita.</para>

    <para>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 <literal>RC</literal>.</para>

    <note>
      <para>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 <filename class="directory">release/doc/</filename> a todos os membros da Equipe de Engenharia de Release do FreeBSD até o <literal>RC</literal> final para atualizar as notas de lançamento e outras documentação relacionada ao lançamento.</para>
    </note>

    <note>
      <para>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.</para>
    </note>

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

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

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

    <note>
      <para>Na maioria dos casos, o <filename>schedule.xml</filename> pode ser copiado de uma versão anterior e atualizado de acordo.</para>
    </note>

    <para>Além de adicionar o <filename>schedule.xml</filename> ao site, o <filename>head/share/xml/navibar.ent</filename> e o <filename>head/share/xml/release.ent</filename> 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.</para>

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

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

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

    <note>
      <para>Se dois ciclos de lançamento paralelo estão acontecendo ao mesmo tempo, a entidade <literal>beta2.local.where</literal> pode ser usada no lugar.</para>
    </note>
  </sect1>

  
<!--
     The FreeBSD Documentation Project

     $FreeBSD$
-->
<sect1 xml:id="releng-terms">
  <title>Terminologia da Engenharia de Release</title>

  <para>Esta seção descreve algumas das terminologias usadas no restante deste documento.</para>

  <sect2 xml:id="releng-terms-code-slush">
    <title>O Code Slush</title>

    <para>Embora o code slush não seja um congelamento mandatório da árvore, a Equipe de Engenharia de Release do FreeBSD solicita que resoluções dos bugs existentes no código tenham prioridade sobre implementação de novos recursos.</para>

    <para>O code slush não impõe aprovações de confirmação para o Branch.</para>
  </sect2>

  <sect2 xml:id="releng-terms-code-freeze">
    <title>O Code Freeze</title>

    <para>O code freeze marca o momento em que todos os commits para a branch exigem aprovação explícita da Equipe de Engenharia de Release do FreeBSD.</para>

    <para>O repositório <application>Subversion</application> do FreeBSD contém vários ganchos para executar verificações de integridade antes que qualquer commit seja realmente confirmado na árvore. Um desses ganchos avaliará se o comprometimento com uma branch específica requer aprovação específica.</para>

    <para>Para impor aprovações de commit pela Equipe de Engenharia de Release do FreeBSD, o Engenheiro de Release atualiza o <filename>base/svnadmin/conf/approvers</filename>, e aplica a mudança de volta para o repositório. Feito isso, qualquer alteração na branch deve incluir uma linha <quote>Aprovado por:</quote> na mensagem de commit.</para>

    <para>A linha <quote>Aprovada por:</quote> deve corresponder à segunda coluna em <filename>base/svnadmin/conf/aprovovers </filename>, caso contrário, o commit será rejeitado pelos hooks do repositório.</para>

    <note>
      <para>Durante o code freeze, os committers do FreeBSD devem seguir as <link xlink:href="https://wiki.freebsd.org/Releng/ChangeRequestGuidelines">Recomendações de Requisição de Mudanças</link>.</para>
    </note>
  </sect2>

  <sect2 xml:id="releng-terms-kbi-freeze">
    <title>O <acronym>KBI</acronym> / Congelamento <acronym>KPI</acronym></title>

    <para>A estabilidade de <acronym>KBI</acronym>/<acronym>KPI</acronym> implica que o caller (que faz uma chamada) de uma função através de duas versões diferentes de software que implementam a função, resulta no mesmo estado final. O caller, seja um processo, thread ou função, espera que a função opere de uma determinada maneira, caso contrário, a estabilidade do <acronym>KBI</acronym>/<acronym>KPI</acronym> na branch é interrompida.</para>
  </sect2>
</sect1>

  
<!--
     The FreeBSD Documentation Project

     $FreeBSD$
-->
<sect1 xml:id="releng-website">
  <title>Alterações na Página Web Durante o Ciclo de Release</title>

  <para>Esta seção descreve as alterações no site que devem ocorrer conforme o ciclo de lançamento progride.</para>

  <note>
    <para>Os arquivos especificados ao longo desta seção são relativos à branch <literal>head/</literal> do repositório <literal>doc</literal> no <application>Subversion</application>.</para>
  </note>

  <sect2 xml:id="releng-website-prerelease">
    <title>Alterações na Página Web Antes do Início do Ciclo de Release</title>

    <para>Quando o cronograma do ciclo de release está disponível, esses arquivos precisam ser atualizados para habilitar várias funcionalidades diferentes no site do Projeto FreeBSD:</para>

    <informaltable frame="none" pgwide="0">
      <tgroup cols="2">
	<thead>
	  <row>
	    <entry>Arquivo para editar</entry>
	    <entry>O que mudar</entry>
	  </row>
	</thead>

	<tbody>
	  <row>
	    <entry><filename>share/xml/release.ent</filename></entry>
	    <entry>Altere <literal>beta.upcoming</literal> de <literal>IGNORE</literal> para <literal>INCLUDE</literal></entry>
	  </row>

	  <row>
	    <entry><filename>share/xml/release.ent</filename></entry>
	    <entry>Altere <literal>% beta.upcoming</literal> de <literal>IGNORE</literal> para <literal>INCLUDE</literal></entry>
	  </row>

	  <row>
	    <entry><filename>share/xml/release.ent</filename></entry>
	    <entry>Altere <literal>beta.testing</literal> de <literal>IGNORE</literal> para <literal>INCLUDE</literal></entry>
	  </row>

	  <row>
	    <entry><filename>share/xml/release.ent</filename></entry>
	    <entry>Altere <literal>% beta.testing</literal> de <literal>IGNORE</literal> para <literal>INCLUDE</literal></entry>
	  </row>
	</tbody>
      </tgroup>
    </informaltable>
  </sect2>

  <sect2 xml:id="releng-website-beta-rc">
    <title>Alterações na página web durante a fase <literal>BETA</literal> ou <literal>RC</literal></title>

    <para>Ao fazer a transição de <literal>PRERELEASE</literal> para <literal>BETA</literal>, esses arquivos precisam ser atualizados para ativar o bloco "Teste de ajuda" na página de download. Todos os arquivos são relativos ao <filename class="directory">head/</filename> no repositório <literal>doc</literal>:</para>

    <informaltable frame="none" pgwide="0">
      <tgroup cols="2">
	<thead>
	  <row>
	    <entry>Arquivo para editar</entry>
	    <entry>O que mudar</entry>
	  </row>
	</thead>

	<tbody>
	  <row>
	    <entry><filename>en_US.ISO8859-1/htdocs/releases/12.0R/schedule.xml</filename></entry>
	    <entry>Altere <literal>% beta.local.where</literal> <literal>IGNORE</literal> para <literal>INCLUDE</literal></entry>
	  </row>

	  <row>
	    <entry><filename>share/xml/release.ent</filename></entry>
	    <entry>Atualize <literal>% betarel.vers</literal> para <literal>BETA<replaceable>1</replaceable></literal></entry>
	  </row>

	  <row>
	    <entry><filename>share/xml/news.xml</filename></entry>
	    <entry>Adicione uma entrada anunciando a versão <literal>BETA</literal></entry>
	  </row>

	  <row>
	    <entry><filename>en_US.ISO8859-1/htdocs/security/advisory-template.txt</filename></entry>
	    <entry>Adicione as novas <literal>BETA</literal>, <literal>RC</literal> ou <literal>RELEASE</literal> final ao modelo</entry>
	  </row>

	  <row>
	    <entry><filename>en_US.ISO8859-1/htdocs/security/errata-template.txt</filename></entry>
	    <entry>Adicione as novas <literal>BETA</literal>, <literal>RC</literal> ou <literal>RELEASE</literal> final ao modelo</entry>
	  </row>
	</tbody>
      </tgroup>
    </informaltable>

    <para>Uma vez criada a branch <literal>releng/<replaceable>12.0</replaceable>/</literal>, os diversos documentos relacionados à release precisam ser gerados e adicionados manualmente ao repositório <literal>doc/</literal>.</para>

    <para>Dentro de <filename class="directory">release/doc</filename>, invoque <citerefentry><refentrytitle>make</refentrytitle><manvolnum>1</manvolnum></citerefentry> para gerar as páginas <filename>errata.html</filename>, <filename>hardware.html</filename>, <filename>readme.html</filename> e <filename>relnotes.html</filename>, que são então adicionadas ao diretório <filename class="directory">doc/head/en_US.ISO8859-1/htdocs/releases/<replaceable>XY</replaceable>R/</filename>, em que <replaceable>XY</replaceable> representa o número da versão principal e da versão secundária.</para>

    <para>A propriedade <literal>fbsd:nokeywords</literal> deve ser definido como <literal>on</literal> nos arquivos recém-adicionados para que os hooks de pré-commit permitam que eles sejam adicionados ao repositório.</para>

    <note>
      <para>Os documentos relevantes relacionados à release existem no repositório <filename class="directory">doc</filename> para FreeBSD 12.x e posterior.</para>
    </note>
  </sect2>

  <sect2 xml:id="releng-ports-beta-rc">
    <title>Mudanças nos ports durante as fases <literal>BETA</literal>, <literal>RC</literal>, e a versão <literal>RELEASE</literal> final</title>

    <para>Para cada compilação durante o ciclo de release, os arquivos <literal>MANIFEST</literal> contendo o <literal>SHA256</literal> dos vários conjuntos de distribuição, como <literal>base.txz</literal>, <literal>kernel.txz</literal>, e assim por diante, são adicionados ao port <package>misc/freebsd-release-manifests</package>. Isso permite outros utilitários além do <citerefentry><refentrytitle>bsdinstall</refentrytitle><manvolnum>8</manvolnum></citerefentry>, como <package>ports-mgmt/poudriere</package>, usem esses conjuntos de distribuição com segurança fornecendo um mecanismo através do qual os checksums possam ser verificados.</para>
  </sect2>
</sect1>

  
<!--
     The FreeBSD Documentation Project

     $FreeBSD$
-->
<sect1 xml:id="releng-head">
  <title>Versões oriundas da branch <literal>head/</literal></title>


  <para>Esta seção descreve os procedimentos gerais do ciclo de release do FreeBSD na branch <literal>head</literal>.</para>

  <sect2 xml:id="releng-head-builds-alpha">
    <title>Compilações <quote><literal>ALPHA</literal></quote> do FreeBSD</title>

    <para>Tendo aparecido primeiramente durante o ciclo de release do FreeBSD 10.0-RELEASE, a noção de compilações de fases <quote><literal>ALPHA</literal></quote> foi introduzida. Ao contrário das compilações <literal>BETA</literal> e <literal>RC</literal>, as compilações desse novo estágio <literal>ALPHA</literal> não fazem parte do cronograma de Release do FreeBSD.</para>

    <para>A idéia por trás das compilações <literal>ALPHA</literal> é disponibilizar builds regulares fornecidas pelo FreeBSD antes da criação da branch <literal>stable/</literal>.</para>

    <para>Os snapshots <literal>ALPHA</literal> do FreeBSD devem ser preparados aproximadamente uma vez por semana.</para>

    <para>Para a primeira compilação <literal>ALPHA</literal>, o valor <varname>BRANCH</varname> em <filename>sys/conf/newvers.sh</filename> precisa ser alterado de <literal>CURRENT</literal> para <literal>ALPHA1</literal>. Para compilações <literal>ALPHA</literal> subsequentes, incremente cada valor de <literal>ALPHA<replaceable>N</replaceable></literal> em um.</para>

    <para>Veja <xref linkend="releng-building"/> para informações sobre como construir as imagens <literal>ALPHA</literal>.</para>
  </sect2>

  <sect2 xml:id="releng-head-branching">
    <title>Criando a branch <literal>stable/<replaceable>12</replaceable>/</literal></title>

    <para>Ao criar a branch <literal>stable/</literal>, várias alterações são necessárias na nova branch <literal>stable/</literal> e na branch <literal>head/</literal>. Os arquivos listados são relativos ao repositório raiz. Para criar a nova branch <literal>stable/<replaceable>12</replaceable>/</literal> no Subversion:</para>

    <screen><prompt>%</prompt> <userinput>svn cp ^/head <literal>stable/<replaceable>12</replaceable>/</literal></userinput></screen>

    <para>Uma vez que a branch <literal>stable/<replaceable>12</replaceable>/</literal> tenha sido criada, faça as seguintes edições:</para>

    <informaltable frame="none" pgwide="0">
      <tgroup cols="2">
	<thead>
	  <row>
	    <entry>Arquivo para editar</entry>
	    <entry>O que mudar</entry>
	  </row>
	</thead>

	<tbody>
	  <row>
	    <entry><filename>stable/<replaceable>12</replaceable>/UPDATING</filename></entry>
	    <entry>Atualize a versão do FreeBSD e remova o aviso sobre <literal>WITNESS</literal></entry>
	  </row>

	  <row>
	    <entry><filename>stable/<replaceable>12</replaceable>/contrib/jemalloc/include/jemalloc/jemalloc_FreeBSD.h</filename></entry>
	    <entry><screen>#ifndef MALLOC_PRODUCTION
#define MALLOC_PRODUCTION
#endif</screen></entry>
	  </row>

	  <row>
	    <entry><filename>stable/<replaceable>12</replaceable>/lib/clang/llvm.build.mk</filename></entry>
	    <entry>Remova o comentário <literal>-DNDEBUG</literal></entry>
	  </row>

	  <row>
	    <entry><filename>stable/<replaceable>12</replaceable>/sys/*/conf/GENERIC*</filename></entry>
	    <entry>Remova o suporte de depuração</entry>
	  </row>

	  <row>
	    <entry><filename>stable/<replaceable>12</replaceable>/sys/*/conf/MINIMAL</filename></entry>
	    <entry>Remova o suporte de depuração</entry>
	  </row>

	  <row>
	    <entry><filename>stable/<replaceable>12</replaceable>/release/release.conf.sample</filename></entry>
	    <entry>Atualize o <varname>SRCBRANCH</varname></entry>
	  </row>

	  <row>
	    <entry><filename>stable/<replaceable>12</replaceable>/sys/*/conf/GENERIC-NODEBUG</filename></entry>
	    <entry>Remova essas configurações do kernel</entry>
	  </row>

	  <row>
	    <entry><filename>stable/<replaceable>12</replaceable>/sys/arm/conf/std.arm*</filename></entry>
	    <entry>Remova as opções de depuração</entry>
	  </row>

	  <row>
	    <entry><filename>stable/<replaceable>12</replaceable>/sys/conf/newvers.sh</filename></entry>
	    <entry>Atualize o valor de <varname>BRANCH</varname> para refletir <literal>BETA1</literal></entry>
	  </row>

	  <row>
	    <entry><filename>stable/<replaceable>12</replaceable>/share/mk/src.opts.mk</filename></entry>
	    <entry>Mova <varname>REPRODUCIBLE_BUILD</varname> de <literal>__DEFAULT_NO_OPTIONS</literal> para <literal>__DEFAULT_YES_OPTIONS</literal></entry>
	  </row>

	  <row>
	    <entry><filename>stable/<replaceable>12</replaceable>/share/mk/src.opts.mk</filename></entry>
	    <entry>Mova <varname>LLVM_ASSERTIONS</varname> de <literal>__DEFAULT_NO_OPTIONS</literal> para <literal>__DEFAULT_YES_OPTIONS</literal> (Apenas para FreeBSD 13.x e posterior)</entry>
	  </row>

	  <row>
	    <entry><filename>stable/<replaceable>12</replaceable>/libexec/rc/rc.conf</filename></entry>
	    <entry>Defina o <literal>dumpdev</literal> de <literal>AUTO</literal> para <literal>NO</literal> (ele é configurável via <citerefentry><refentrytitle>bsdinstall</refentrytitle><manvolnum>8</manvolnum></citerefentry> para aqueles que o querem habilitado por padrão)</entry>
	  </row>

	  <row>
	    <entry><filename>stable/<replaceable>12</replaceable>/release/Makefile</filename></entry>
	    <entry>Remova as entradas <literal>debug.witness.trace</literal></entry>
	  </row>
	</tbody>
      </tgroup>
    </informaltable>

    <para>Então, na branch <literal>head/</literal>, que agora se tornará uma nova versão principal:</para>

    <informaltable frame="none" pgwide="0">
      <tgroup cols="2">
	<thead>
	  <row>
	    <entry>Arquivo para editar</entry>
	    <entry>O que mudar</entry>
	  </row>
	</thead>

	<tbody>
	  <row>
	    <entry><filename>head/UPDATING</filename></entry>
	    <entry>Atualize a versão do FreeBSD</entry>
	  </row>

	  <row>
	    <entry><filename>head/sys/conf/newvers.sh</filename></entry>
	    <entry>Atualize o valor de <varname>BRANCH</varname> para refletir <literal>CURRENT</literal> e incremente a <literal>REVISION</literal></entry>
	  </row>

	  <row>
	    <entry><filename>head/Makefile.inc1</filename></entry>
	    <entry>Atualize o <literal>TARGET_TRIPLE</literal> e o <literal>MACHINE_TRIPLE</literal></entry>
	  </row>

	  <row>
	    <entry><filename>head/sys/sys/param.h</filename></entry>
	    <entry>Atualize o <literal>__FreeBSD_version</literal></entry>
	  </row>

	  <row>
	    <entry><filename>head/gnu/usr.bin/cc/cc_tools/freebsd-native.h</filename></entry>
	    <entry>Atualize o <literal>FBSD_MAJOR</literal> e o <literal>FBSD_CC_VER</literal></entry>
	  </row>

	  <row>
	    <entry><filename>head/contrib/gcc/config.gcc</filename></entry>
	    <entry>Anexe a seção <literal>freebsd&lt;versão&gt;.h</literal></entry>
	  </row>

	  <row>
	    <entry><filename>head/lib/clang/llvm.build.mk</filename></entry>
	    <entry>Atualize o valor do <literal>OS_VERSION</literal></entry>
	  </row>

	  <?ignore <row>
	    <entry><filename>head/release/doc/en_US.ISO8859-1/readme/article.xml</filename></entry>
	    <entry>Replace &amp;a.current; with &amp;a.stable;</entry>
	  </row>

	  ?>

	  <?ignore <row>
	    <entry><filename>head/release/doc/share/xml/release.ent</filename></entry>
	    <entry></entry>
	  </row>

	  ?>

	  <row>
	    <entry><filename>head/lib/clang/freebsd_cc_version.h</filename></entry>
	    <entry>Atualize o <literal>FREEBSD_CC_VERSION</literal></entry>
	  </row>

	  <row>
	    <entry><filename>head/lib/clang/include/lld/Common/Version.inc</filename></entry>
	    <entry>Atualize o <literal>LLD_REVISION_STRING</literal></entry>
	  </row>

	  <row>
	    <entry><filename>head/Makefile.libcompat</filename></entry>
	    <entry>Atualize o <literal>LILB32CPUFLAGS</literal></entry>
	  </row>
	</tbody>
      </tgroup>
    </informaltable>
  </sect2>
</sect1>

  
<!--
     The FreeBSD Documentation Project

     $FreeBSD$
-->
<sect1 xml:id="releng-stable">
  <title>Release a partir da branch <literal>stable/</literal></title>

  <para>Esta seção descreve os procedimentos gerais do ciclo de release do FreeBSD a partir de uma branch <literal>stable/</literal>.</para>

  <sect2 xml:id="releng-stable-slush">
    <title>Code Slush da branch <literal>stable</literal> do FreeBSD</title>

    <para>Na preparação para o code freeze em uma branch <literal>stable</literal>, 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:</para>

    <informaltable frame="none" pgwide="0">
      <tgroup cols="2">
	<thead>
	  <row>
	    <entry>Arquivo para editar</entry>
	    <entry>O que mudar</entry>
	  </row>
	</thead>

	<tbody>
	  <row>
	    <entry><filename>sys/conf/newvers.sh</filename></entry>
	    <entry>Atualize o valor da <varname>BRANCH</varname> para refletir <literal>PRERELEASE</literal></entry>
	  </row>

	  <row>
	    <entry><filename>Makefile.inc1</filename></entry>
	    <entry>Atualize o <varname>TARGET_TRIPLE</varname></entry>
	  </row>

	  <row>
	    <entry><filename>lib/clang/llvm.build.mk</filename></entry>
	    <entry>Atualize o <varname>OS_VERSION</varname></entry>
	  </row>

	  <row>
	    <entry><filename>Makefile.libcompat</filename></entry>
	    <entry>Atualize o <literal>LIB32CPUFLAGS</literal></entry>
	  </row>

	  <row>
	    <entry><filename>gnu/usr.bin/groff/tmac/mdoc.local.in</filename></entry>
	    <entry>Adiciona uma nova entrada <literal>.ds</literal> para a versão do FreeBSD, e atualiza <varname>doc-default-operating-system</varname> (FreeBSD 11.x e anteriores apenas)</entry>
	  </row>
	</tbody>
      </tgroup>
    </informaltable>

    <para>No repositório <literal>doc</literal>, atualize também <filename>head/pt_BR.ISO8859-1/htdocs/releases/<replaceable>12.0</replaceable>R/Makefile.hardware</filename>, alternando o valor de <varname>_BRANCH</varname> para <literal>BETA<replaceable>X</replaceable></literal>, <literal>RC<replaceable>X</replaceable></literal> ou <literal>RELEASE</literal>, respectivamente.</para>

  </sect2>

  <sect2 xml:id="releng-stable-builds-beta">
    <title>Builds <literal>BETA</literal> do FreeBSD</title>

    <para>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 <filename>base/svnadmin/conf/approvers</filename> para incluir uma expressão regular que coincida com a  branch <literal>stable/<replaceable>12</replaceable>/</literal> para a release:</para>

    <programlisting>^/<literal>stable/<replaceable>12</replaceable>/</literal>	re
^/<literal>releng/<replaceable>12.0</replaceable>/</literal>	re</programlisting>

    <note>
      <para>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.</para>
    </note>

    <para>Quando o code freeze estiver em vigor, a próxima construção da branch será rotulada como <literal>BETA1</literal>. Isso é feito atualizando o valor de <varname>BRANCH</varname> em <filename>sys/conf/newvers.sh</filename> de <literal>PRERELEASE</literal> para <literal>BETA1</literal>.</para>

    <para>Feito isso, o primeiro conjunto de builds <literal>BETA</literal> é iniciado. Builds <literal>BETA</literal> subseqüentes não requerem atualizações em nenhum arquivo diferente do <filename>sys/conf/newvers.sh</filename>, incrementando o número de compilação da versão <literal>BETA</literal>.</para>
  </sect2>

  <sect2 xml:id="releng-stable-branching">
    <title>Criando a branch <literal>releng/<replaceable>12.0</replaceable>/</literal></title>

    <para>Quando a primeira construção <literal>RC</literal> (Release Candidate) está pronta para começar, a branch <literal>releng/</literal> é 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 <varname>__ FreeBSD_version</varname>, por exemplo. Os caminhos listados abaixo são relativos ao repositório raiz. A ordem dos commits e o que mudar são:</para>

    <screen><prompt>%</prompt> <userinput>svn cp ^/<literal>stable/<replaceable>12</replaceable>/</literal> <literal>releng/<replaceable>12.0</replaceable>/</literal></userinput></screen>

    <informaltable frame="none" pgwide="0">
      <tgroup cols="2">
	<thead>
	  <row>
	    <entry>Arquivo para editar</entry>
	    <entry>O que mudar</entry>
	  </row>
	</thead>

	<tbody>
	  <row>
	    <entry><filename>releng/<replaceable>12.0</replaceable>/sys/conf/newvers.sh</filename></entry>
	    <entry>Altere <literal>BETA<replaceable>X</replaceable></literal> para <literal>RC1</literal></entry>
	  </row>

	  <row>
	    <entry><filename>releng/<replaceable>12.0</replaceable>/sys/sys/param.h</filename></entry>
	    <entry>Atualize o <varname>__ FreeBSD_version</varname></entry>
	  </row>

	  <row>
	    <entry><filename>releng/<replaceable>12.0</replaceable>/etc/pkg/FreeBSD.conf</filename></entry>
	    <entry>Substitua <literal>latest</literal> por <literal>quarterly</literal> (trimestral) como a localização padrão do repositório de pacotes</entry>
	  </row>

	  <row>
	    <entry><filename>releng/<replaceable>12.0</replaceable>/release/pkg_repos/release-dvd.conf</filename></entry>
	    <entry>Substitua <literal>latest</literal> por <literal>quarterly</literal> (trimestral) como a localização padrão do repositório de pacotes</entry>
	  </row>

	  <row>
	    <entry><filename>stable/<replaceable>12</replaceable>/sys/conf/newvers.sh</filename></entry>
	    <entry>Atualize <literal>BETA<replaceable>X</replaceable></literal> para <literal>PRERELEASE</literal></entry>
	  </row>

	  <row>
	    <entry><filename>stable/<replaceable>12</replaceable>/sys/sys/param.h</filename></entry>
	    <entry>Atualize o <varname>__ FreeBSD_version</varname></entry>
	  </row>

	  <row>
	    <entry><filename>svnadmin/conf/approvers</filename></entry>
	    <entry>Adicione uma nova linha de aprovadores para a branch releng como foi feito para a branch stable</entry>
	  </row>
	</tbody>
      </tgroup>
    </informaltable>

    <screen><prompt>%</prompt> <userinput>svn propdel -R svn:mergeinfo <literal>releng/<replaceable>12.0</replaceable>/</literal></userinput>
<prompt>%</prompt> <userinput>svn commit <literal>releng/<replaceable>12.0</replaceable>/</literal></userinput>
<prompt>%</prompt> <userinput>svn commit <literal>stable/<replaceable>12</replaceable>/</literal></userinput></screen>

    <para>Agora que existem dois novos valores de <varname>__ FreeBSD_version</varname>, também atualize <filename>head/pt_BR.ISO8859-1/books/porters-handbook/versions/chapter.xml</filename> no repositório do Projeto de Documentação.</para>

    <para>Depois que a primeira compilação de um <literal>RC</literal> estiver concluída e testada, a branch <literal>stable/</literal> pode ser <quote>descongelada</quote> removendo (ou comentando) a entrada ^/<literal>stable/<replaceable>12</replaceable>/</literal> em <filename>svnadmin/conf/approvers</filename>.</para>

    <para>Seguindo a disponibilidade do primeiro <literal>RC</literal>, o Time Bugmeister do FreeBSD deve ser avisado por e-mail para adicionar o novo FreeBSD <literal>-RELEASE</literal> às <literal>versões</literal> disponíveis no menu drop-down exibido no rastreador de bugs.</para>
  </sect2>
</sect1>

  
<!--
     The FreeBSD Documentation Project

     $FreeBSD$
-->
<sect1 xml:id="releng-building">
  <title>Construindo a Mídia de Instalação do FreeBSD</title>

  <para>Esta seção descreve os procedimentos gerais de produção de snapshots e releases de desenvolvimento do FreeBSD.</para>

  <sect2 xml:id="releng-build-scripts">
    <title>Scripts para compilação de Releases</title>

    <para>Esta seção descreve os scripts de build usados pela Equipe de Engenharia de Release do FreeBSD para produzir snapshots da versão em desenvolvimento e das releases.</para>

    <sect3 xml:id="releng-build-scripts-single">
      <title>O script <filename>release.sh</filename></title>

      <para>Antes do FreeBSD 9.0-RELEASE, o <filename>src/release/Makefile</filename> era atualizado para suportar o <citerefentry><refentrytitle>bsdinstall</refentrytitle><manvolnum>8</manvolnum></citerefentry>, e o script <filename>src/release/generate-release.sh</filename> foi introduzido como um wrapper para automatizar a chamada dos targets <citerefentry><refentrytitle>release</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>

      <para>Antes do FreeBSD 9.2-RELEASE, foi introduzido o <filename>src/release/release.sh</filename>, que baseado fortemente em <filename>src/release/generate-release.sh</filename> incluía suporte para especificar arquivos de configuração para substituir várias opções e variáveis de ambiente. O suporte para arquivos de configuração forneceu suporte para cross building (compilação para mais de uma arquitetura) de uma release para cada arquitetura, especificando um arquivo de configuração separado para cada chamada.</para>

      <para>Como um breve exemplo do uso de <filename>src/release/release.sh</filename> para construir uma única versão em <filename class="directory">/scratch</filename>:</para>

      <screen><prompt>#</prompt> <userinput>/bin/sh /usr/src/release/release.sh</userinput></screen>

      <para>Como um breve exemplo do uso de <filename>src/release/release.sh</filename> para construir uma única versão cross-build (entre arquiteturas) usando um diretório de destino diferente, crie um <filename>release.conf</filename> personalizado contendo:</para>

      <programlisting># release.sh configuration for powerpc/powerpc64
CHROOTDIR="/scratch-powerpc64"
TARGET="powerpc"
TARGET_ARCH="powerpc64"
KERNEL="GENERIC64"</programlisting>

      <para>Em seguida, invoque <filename>src/release/release.sh</filename> da seguinte forma:</para>

      <screen><prompt>#</prompt> <userinput>/bin/sh /usr/src/release/release.sh -c <replaceable>$HOME/release.conf</replaceable></userinput></screen>

      <para>Veja <citerefentry><refentrytitle>release</refentrytitle><manvolnum>7</manvolnum></citerefentry> e <filename>src/release/release.conf.sample</filename> para mais detalhes e exemplos de uso.</para>
    </sect3>

    <sect3 xml:id="releng-build-scripts-multiple">
      <title>O Script Wrapper <filename>thermite.sh</filename></title>

      <para>Para tornar o cross building do conjunto completo de arquiteturas suportadas em uma determinada branch mais rápido, mais fácil e reduzindo os fatores de erro humano, um script wrapper de apoio ao <filename>src/release/release.sh</filename> foi escrito para iterar pelas várias combinações de arquiteturas e chamar o script <filename>src/release/release.sh</filename> usando um arquivo de configuração específico para essa arquitetura.</para>

      <para>O script wrapper é chamado de <filename>thermite.sh</filename>, o qual está disponível no repositório Subversion do FreeBSD em <literal>svn://svn.freebsd.org/base/user/gjb/thermite/</literal> , além dos arquivos de configuração usados para construir os snapshots de desenvolvimento <literal>head/</literal> e <literal>stable/<replaceable>12</replaceable>/</literal>.</para>

      <para>O uso do <filename>thermite.sh</filename> é explicado em <xref linkend="releng-build-snapshot"/> e <xref linkend="releng-build-release"/>.</para>

      <para>Cada arquitetura e kernel individual tem seu próprio arquivo de configuração usado pelo <filename>release.sh</filename>. Cada branch tem sua própria configuração <filename>defaults-X.conf</filename> que contém entradas comuns em cada arquitetura, onde substituições ou variáveis especiais são definidas e/ou substituídas nos arquivos por compilação.</para>

      <para>O esquema de nomenclatura do arquivo de configuração por compilação está na forma de <filename>${revision}-${TARGET_ARCH}-${KERNCONF}-${type}.conf</filename>, em que as variáveis em maiúsculas são equivalentes a que <citerefentry><refentrytitle>make</refentrytitle><manvolnum>1</manvolnum></citerefentry> usa no sistema de compilação e as variáveis minúsculas são definidas nos arquivos de configuração, mapeando para a versão principal da respectiva branch.</para>

      <para>Cada branch também possui sua própria configuração <filename>builds-X.conf</filename>, que é usada pelo <filename>thermite.sh</filename>. O script <filename>thermite.sh</filename> itera através de cada valor ${revision}, ${TARGET_ARCH}, ${KERNCONF} e ${type}, criando uma lista principal do que construir. No entanto, uma determinada combinação da lista só será criada se o respectivo arquivo de configuração existir, que é onde o esquema de nomenclatura acima é relevante.</para>

      <para>Existem dois caminhos de fornecimento de arquivos:</para>

      <itemizedlist>
	<listitem>
	  <para><filename>builds-<replaceable>12</replaceable>.conf</filename> -&gt; <filename>main.conf</filename></para>
	  <para>Isto controla o comportamento do <filename>thermite.sh</filename></para>
	</listitem>

	<listitem>
	  <para><filename><replaceable>12</replaceable>-<replaceable>amd64</replaceable>-<replaceable>GENERIC</replaceable>-<replaceable>snap</replaceable>.conf</filename> -&gt; <filename>defaults-<replaceable>12</replaceable>.conf</filename> -&gt; <filename>main.conf</filename></para>
	  <para>Isto controla o comportamento do <filename>release/release.sh</filename> dentro do <citerefentry><refentrytitle>chroot</refentrytitle><manvolnum>8</manvolnum></citerefentry> de compilação</para>
	</listitem>
      </itemizedlist>

      <note>
	<para>Os arquivos de configuração <filename>builds-<replaceable>12</replaceable>.conf</filename>, <filename>defaults-<replaceable>12</replaceable>.conf</filename>, e <filename>main.conf</filename> existem para reduzir a repetição entre os vários arquivos por compilação.</para>
      </note>
    </sect3>
  </sect2>

  <sect2 xml:id="releng-build-snapshot">
    <title>Construindo Snapshots de Desenvolvimento do FreeBSD</title>

    <para>As máquinas oficiais de compilação de versões têm um layout do sistema de arquivos específico, que utiliza <acronym>ZFS</acronym>, o <filename>thermite.sh</filename> tira grande proveito de clones e snapshots, garantindo um ambiente de compilação uniforme e consistente.</para>

    <para>Os scripts de compilação localizam-se respectivamente em <filename class="directory">/releng/scripts-snapshot/scripts</filename> ou <filename class="directory">/releng/scripts-release/scripts</filename>, para evitar colisões entre uma compilação <literal>RC</literal> de uma branch releng contra um snapshot <literal>STABLE</literal> da respectiva branch stable.</para>

    <para>Existe um dataset (conjunto de dados) separado para as imagens finais de compilação, <filename class="directory">/snap/ftp</filename>. Este diretório contém diretórios de snapshots e releases. Eles são usados apenas se a variável <literal>EVERYTHINGISFINE</literal> estiver definida em <filename>main.conf</filename>.</para>

    <note>
      <para>O nome da variável <literal>EVERYTHINGISFINE</literal> foi escolhido para evitar a colisão com uma variável possivelmente definida no ambiente do usuário, ativando acidentalmente o comportamento que depende de sua definição.</para>
    </note>

    <para>Como o <filename>thermite.sh</filename> percorre a lista principal de combinações e localiza o arquivo de configuração por compilação, um dataset <acronym>ZFS</acronym> é criado sob o <filename class="directory">/releng</filename>, tal como <filename class="directory">/releng/12-amd64-GENERIC-snap</filename>. O checkout das árvores <literal>src/</literal>, <literal>ports/</literal> e <literal>doc/</literal> é realizado em diferentes datasets <acronym>ZFS</acronym>, tal como <filename class="directory">/releng/12-src-snap</filename>, os quais são então clonados e montados nos respectivos datasets de compilação. Isso é feito para evitar a remoção de uma determinada árvore mais de uma vez.</para>

    <para>Assumindo esses caminhos do sistema de arquivos, o <filename>thermite.sh</filename> deveria ser chamado como:</para>

    <screen><prompt>#</prompt> <userinput>cd /releng/scripts-snapshot/scripts</userinput>
<prompt>#</prompt> <userinput>./setrev.sh -b <literal>stable/<replaceable>12</replaceable>/</literal></userinput>
<prompt>#</prompt> <userinput>./zfs-cleanup.sh -c ./builds-<replaceable>12</replaceable>.conf</userinput>
<prompt>#</prompt> <userinput>./thermite.sh -c ./builds-<replaceable>12</replaceable>.conf</userinput></screen>

    <para>Quando as compilações forem concluídas, scripts adicionais auxiliares estarão disponíveis para gerar e-mails de snapshots de desenvolvimento que são enviados para a lista de e-mail <literal>freebsd-snapshots@freebsd.org</literal>:</para>

    <screen><prompt>#</prompt> <userinput>cd /releng/scripts-snapshot/scripts</userinput>
<prompt>#</prompt> <userinput>./get-checksums.sh -c ./builds-<replaceable>12</replaceable>.conf | ./generate-email.pl &gt; snapshot-<replaceable>12</replaceable>-mail</userinput></screen>

    <note>
      <para>A saída gerada deve ser checada duas vezes para garantir a exatidão, e o próprio e-mail deve ter assinatura PGP, in-line (no arquivo).</para>
    </note>

    <note>
      <para>Esses scripts auxiliares aplicam-se apenas às compilações de snapshot (versão instantânea) de desenvolvimento. Os anúncios durante o ciclo de lançamento (excluindo o anúncio de versão final) são criados a partir de um modelo de email. Uma amostra do modelo de email usado atualmente pode ser encontrada <link xlink:href="https://svn.freebsd.org/base/user/gjb/thermite/non-release-template-mail.txt">aqui</link>.</para>
    </note>
  </sect2>

  <sect2 xml:id="releng-build-release">
    <title>Construindo Releases do FreeBSD</title>

    <para>Similar a compilação de snapshots de desenvolvimento do FreeBSD, o <filename>thermite.sh</filename> seria invocado da mesma maneira. A diferença entre snapshots de desenvolvimento e builds de releases, <literal>BETA</literal> e <literal>RC</literal> inclusos, é que os arquivos de configuração do <citerefentry><refentrytitle>chroot</refentrytitle><manvolnum>8</manvolnum></citerefentry> devem ser nomeados com <literal>release</literal> ao invés de <literal>snap</literal> no "type", como mencionado acima.</para>

    <para>Além disso, <literal>BUILDTYPE</literal> e <literal>types</literal> devem ser alterados de <literal>snap</literal> para <literal>release</literal> em <filename>defaults-<replaceable>12</replaceable>.conf</filename> e <filename>builds-<replaceable>12</replaceable>.conf</filename>, respectivamente.</para>

    <para>Ao construir o <literal>BETA</literal>, o <literal>RC</literal>, e o <literal>RELEASE</literal> final, também ajuste estaticamente o <literal>BUILDSVNREV</literal> para a revisão na branch refletindo a mudança de nome, <literal>BUILDDATE</literal> para a data em que as compilações são iniciadas no formato <literal>YYYYMMDD</literal>. Se as árvores <literal>doc/</literal> e <literal>ports/</literal> tiverem sido marcadas, defina também o <literal>PORTBRANCH</literal> e o <literal>DOCBRANCH</literal> para o caminho da tag relevante no repositório Subversion, substituindo <literal>HEAD</literal> pela última revisão alterada. Também defina <literal>releasesrc</literal> em <filename>builds-<replaceable>12</replaceable>.conf </filename> para a branch relevante, como <literal>stable/<replaceable>12</replaceable>/</literal> ou <literal>releng/<replaceable>12.0</replaceable>/</literal>.</para>

    <para>Durante o ciclo de release, uma cópia do <filename>CHECKSUM.SHA512</filename> e do <filename>CHECKSUM.SHA256</filename> para cada arquitetura é armazenada no repositório interno da Equipe de Engenharia de Release do FreeBSD, além de ser incluída nos diversos e-mails de anúncio. Cada <filename>MANIFEST</filename> contendo os hashes do <filename>base.txz</filename>, do <filename>kernel.txz</filename>, etc. também são adicionados ao <package>misc/freebsd-release-manifests</package> na coleção de ports.</para>

    <para>Na preparação para a compilação da release, vários arquivos precisam ser atualizados:</para>

    <informaltable frame="none" pgwide="0">
      <tgroup cols="2">
	<thead>
	  <row>
	    <entry>Arquivo para editar</entry>
	    <entry>O que mudar</entry>
	  </row>
	</thead>

	<tbody>
	  <row>
	    <entry><filename>sys/conf/newvers.sh</filename></entry>
	    <entry>Atualize o valor <varname>BRANCH</varname> para <literal>RELEASE</literal></entry>
	  </row>

	  <row>
	    <entry><filename>UPDATING</filename></entry>
	    <entry>Adicione a data prevista do anúncio</entry>
	  </row>

	  <row>
	    <entry><filename>lib/csu/common/crtbrand.c</filename></entry>
	    <entry>Altere <literal>__FreeBSD_version</literal> com o valor em <filename>sys/sys/param.h</filename></entry>
	  </row>
	</tbody>
      </tgroup>
    </informaltable>

    <para>Depois de construir a <literal>RELEASE</literal> final, a branch <literal>releng/<replaceable>12.0</replaceable>/</literal> é marcada como <literal>release/<replaceable>12.0.0</replaceable>/</literal> usando a revisão a partir da qual a <literal>RELEASE</literal> foi construída. Semelhante a criar as branches <literal>stable/<replaceable>12</replaceable>/</literal> e <literal>releng/<replaceable>12.0</replaceable>/</literal>, isso é feito com <command>svn cp</command>. Da raiz do repositório:</para>

    <screen><prompt>%</prompt> <userinput>svn cp ^/<literal>releng/<replaceable>12.0</replaceable>/</literal>@r<replaceable>306420</replaceable> <literal>release/<replaceable>12.0.0</replaceable>/</literal></userinput>
<prompt>%</prompt> <userinput>svn commit <literal>release/<replaceable>12.0.0</replaceable>/</literal></userinput></screen>
  </sect2>
</sect1>

  
<!--
     The FreeBSD Documentation Project

     $FreeBSD$
-->
<sect1 xml:id="releng-mirrors">
  <title>Publicando a Mídia de Instalação do FreeBSD nos Espelhos do Projeto</title>

  <para>Esta seção descreve o procedimento para publicar snapshots e releases de desenvolvimento do FreeBSD nos espelhos do Projeto.</para>

  <sect2 xml:id="releng-mirrors-staging">
    <title>Preparando Imagens de Mídias de Instalação do FreeBSD</title>

    <para>A preparação dos snapshots e das versões do FreeBSD é um processo de duas partes:</para>

    <itemizedlist>
      <listitem>
	<para>Criando a estrutura de diretórios para corresponder a hierarquia em <systemitem>ftp-master</systemitem></para>

	<para>Se <literal>EVERYTHINGISFINE</literal> for definido nos arquivos de configuração de compilação, <filename>main.conf</filename> no caso dos scripts de compilação mencionados acima, isto acontece automaticamente no <citerefentry><refentrytitle>chroot</refentrytitle><manvolnum>8</manvolnum></citerefentry> após a compilação ser concluída, criando a estrutura de diretório em <filename class="directory">${DESTDIR}/R/ftp-stage</filename> com um estrutura de caminho que corresponde ao que é esperado em <systemitem>ftp-master</systemitem>. Isto é equivalente a executar o seguinte diretamente no <citerefentry><refentrytitle>chroot</refentrytitle> <manvolnum>8</manvolnum></citerefentry>:</para>

	<screen><prompt>#</prompt> <userinput>make -C /usr/src/release -f Makefile.mirrors EVERYTHINGISFINE=1 ftp-stage</userinput></screen>

	<para>Depois que cada arquitetura é compilada, o <filename>thermite.sh</filename> irá fazer um <application>rsync</application> do <filename class="directory">${DESTDIR}/R/ftp-stage</filename> da compilação <citerefentry><refentrytitle>chroot</refentrytitle><manvolnum>8</manvolnum></citerefentry> para o diretório <filename class="directory">/snap/ftp/snapshots</filename> ou <filename class="directory">/snap/ftp/releases</filename> no host de compilação, respectivamente.</para>
      </listitem>

      <listitem>
	<para>Copiando os arquivos para um diretório temporário em <systemitem>ftp-master </systemitem> antes de mover os arquivos para <filename class="directory">pub/</filename> para iniciar a propagação para os servidores espelhos do Projeto</para>

	<para>Uma vez que todas as compilações terminarem, <filename class="directory">/snap/ftp/snapshots</filename>, ou <filename class="directory">/snap/ftp/releases</filename> para uma versão, é pesquisado pelo <systemitem>ftp-master</systemitem> usando <application>rsync</application> para <filename class="directory">/archive/tmp/snapshots</filename> ou <filename class="directory">/archive/tmp/releases</filename>, respectivamente.</para>

	<note>
	  <para>No <systemitem>ftp-master</systemitem> na infraestrutura do Projeto FreeBSD, esta etapa requer acesso ao nível de <literal>root</literal>, já que esta etapa deve ser executada como o usuário <literal>archive</literal>.</para>
	</note>
      </listitem>
    </itemizedlist>
  </sect2>

  <sect2 xml:id="releng-mirrors-publishing">
    <title>Publicando a Mídia de Instalação do FreeBSD</title>

    <para>Uma vez que as imagens são colocadas em <filename class="directory">/archive/tmp/</filename>, elas estão prontas para serem publicadas colocando-as em <filename class="directory">/archive/pub/FreeBSD</filename>. Para reduzir o tempo de propagação, o <citerefentry><refentrytitle>pax</refentrytitle><manvolnum>1</manvolnum></citerefentry> é usado para criar links físicos a partir de <filename class="directory">/archive/tmp</filename> para <filename class="directory">/archive/pub/FreeBSD</filename>.</para>

    <note>
      <para>Para que isto seja efetivo, tanto o <filename class="directory">/archive/tmp</filename> quanto o  <filename class="directory">/archive/pub</filename> devem residir no mesmo sistema de arquivos lógico.</para>
    </note>

    <para>Há uma ressalva, no entanto, em que o <application>rsync</application> deve ser usado após o <citerefentry><refentrytitle>pax</refentrytitle><manvolnum>1</manvolnum></citerefentry> para corrigir os links simbólicos no <filename class="directory">pub/FreeBSD/<replaceable>snapshots</replaceable>/ISO-IMAGES</filename> que o <citerefentry><refentrytitle>pax</refentrytitle><manvolnum>1</manvolnum></citerefentry> irá substituir por um hard link, aumentando o tempo de propagação.</para>

    <note>
      <para>Assim como nas etapas de preparação, isto requer acesso em nível de <literal>root</literal>, já que essa etapa deve ser executada como o usuário  <literal>archive</literal>.</para>
    </note>

    <para>Como o usuário <literal>archive</literal>:</para>

    <screen><prompt>%</prompt> <userinput>cd /archive/tmp/<replaceable>snapshots</replaceable></userinput>
<prompt>%</prompt> <userinput>pax -r -w -l . /archive/pub/FreeBSD/<replaceable>snapshots</replaceable></userinput>
<prompt>%</prompt> <userinput>/usr/local/bin/rsync -avH /archive/tmp/<replaceable>snapshots</replaceable>/* /archive/pub/FreeBSD/<replaceable>snapshots</replaceable>/</userinput></screen>

    <para>Substitua os <replaceable>snapshots</replaceable> por <replaceable>releases</replaceable> conforme apropriado.</para>
  </sect2>
</sect1>


  <sect1 xml:id="releng-wrapup">
    <title>Encerrando o Ciclo de Release</title>

    <para>Esta seção descreve as tarefas gerais de pós-release.</para>

    <sect2 xml:id="releng-wrapup-en">
      <title>Avisos de Erratas de Pós-Release</title>

      <para>A medida que o ciclo de release se aproxima da conclusão, é comum ter vários candidatos a <acronym>EN</acronym> (Aviso de Erratas) para abordar os problemas que foram descobertos ao final do ciclo. Após o lançamento, a Equipe de Engenharia de Release do FreeBSD e a Equipe de Segurança do FreeBSD reveem mudanças que não foram aprovadas antes da versão final, e dependendo do escopo da mudança em questão, podem emitir um <acronym>EN</acronym>.</para>

      <note>
	<para>O processo atual de emissão de <acronym>EN</acronym>s é tratado pela Equipe de Segurança do FreeBSD.</para>
      </note>

      <para>Para solicitar uma Errata após a conclusão de um ciclo de lançamento, o desenvolvedor deve preencher o <link xlink:href="https://www.freebsd.org/security/errata-template.txt">Template de Errata</link>&gt;, em particular as seções <literal>Background</literal>, <literal>Problem Description</literal>, <literal>Impact</literal> e, se aplicável, as seções <literal>Workaround</literal>.</para>

      <para>O modelo de Errata preenchido deve ser enviado por e-mail juntamente com um patch na branch <literal>releng/</literal> ou uma lista de revisões da branch <literal>stable/</literal>.</para>

      <para>Para pedidos de Errata imediatamente após o lançamento, o pedido deve ser enviado por e-mail à Equipe de Engenharia de Releases do FreeBSD e à Equipe de Segurança do FreeBSD. Depois que a branch <literal>releng/</literal> foi entregue à equipe de Segurança do FreeBSD, conforme descrito em <xref linkend="releng-wrapup-handoff"/>, as solicitações de Errata devem ser enviadas à equipe de Segurança do FreeBSD.</para>
    </sect2>

    <sect2 xml:id="releng-wrapup-handoff">
      <title>Entrega para a Equipe de Segurança do FreeBSD</title>

      <para>Aproximadamente duas semanas após o lançamento, o Engenheiro de Release atualiza o <filename>svnadmin/conf/approvers</filename> alterando a coluna do aprovador de <literal>re</literal> para <literal>(so|security-officer)</literal> para a branch <literal>releng/<replaceable>12.0</replaceable>/</literal>.</para>
    </sect2>
  </sect1>

</article>