aboutsummaryrefslogtreecommitdiff
path: root/pt_BR.ISO8859-1/articles/releng/article.xml
blob: 8dbbae3785e1ab967a5287ff52e66c8b11611aba (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
<?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">
<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>

    <confgroup>
      <confdates>Novembro de 2001</confdates>
      <conftitle>BSDCon Europa</conftitle>
    </confgroup>

    <authorgroup>
      <author><personname> <firstname>Murray</firstname> <surname>Stokely</surname> </personname> <personblurb>
	  <para>Eu estive envolvido no desenvolvimento de produtos baseados no FreeBSD desde 1997 na Walnut Creek CDROM, BSDi e agora na Wind River Systems. O FreeBSD 4.4 foi o primeiro release oficial do FreeBSD no qual eu participei de forma significativa.</para>
	</personblurb> <affiliation> <address>
	    <email>murray@FreeBSD.org</email>
	    <otheraddr xlink:href="https://people.FreeBSD.org/~murray/">https://people.FreeBSD.org/~murray/</otheraddr>
	  </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>
	<note>
	  <para>Este documento está desatualizado e não descreve com precisão os procedimentos atuais de lançamentos da equipe de Engenharia de Release (Versão) do FreeBSD. É retido para fins históricos. Os procedimentos atuais usados pela equipe de Engenharia de Release do FreeBSD estão disponíveis no artigo <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/articles/freebsd-releng/article.html">Engenharia de Release do FreeBSD</link>.</para></note></para>

	  <para>Este artigo descreve a abordagem usada pela equipe de engenharia de release do FreeBSD para produzir versões  do Sistema Operacional FreeBSD com qualidade de produção. Ele detalha a metodologia utilizada para as versões oficiais do FreeBSD e descreve as ferramentas disponíveis para aqueles interessados em produzir versões customizadas do FreeBSD para uso corporativo ou para uso em produtos comerciais.</para>
    </abstract>
  </info>

<!-- Introduction -->
    <sect1 xml:id="introduction">
      <title>Introdução</title>

      <para>O desenvolvimento do FreeBSD é um processo muito aberto. O FreeBSD é composto por contribuições de milhares de pessoas em todo o mundo. O Projeto FreeBSD fornece acesso ao Subversion <footnote>
	<simpara>Subversion, <uri xlink:href="http://subversion.apache.org">http://subversion.apache.org</uri></simpara></footnote> para o público em geral para que outros possam ter acesso a mensagens de log, diffs (patches) entre branches (ramificações) de desenvolvimento e outros aprimoramentos de produtividade que o gerenciamento formal de código-fonte proporciona. Isso tem sido uma grande ajuda na atração de desenvolvedores talentosos para o FreeBSD. No entanto, acho que todos concordariam que o caos logo se manifestaria se o acesso para modificar o repositório principal fosse aberto a todos na Internet. Dessa forma, apenas um grupo <quote>seleto</quote> de quase 300 pessoas recebe acesso de escrita ao repositório do Subversion. Estes <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/articles/contributors/article.html#staff-committers">committers</link> <footnote>
	  <simpara><link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/articles/contributors/article.html#staff-committers">Committers do FreeBSD</link></simpara>
	</footnote> são normalmente as pessoas que fazem a maior parte do desenvolvimento do FreeBSD. Um <link xlink:href="@@URL_RELPREFIX@@/administration.html#t-core">Core team</link> <footnote>
	  <simpara><link xlink:href="@@URL_RELPREFIX@@/administration.html#t-core">Core Team do FreeBSD</link></simpara>
	</footnote> eleito fornece algum nível de orientação sobre o projeto.</para>

      <para>O ritmo acelerado de desenvolvimento do <systemitem>FreeBSD</systemitem> torna a principal branch de desenvolvimento inadequada para o uso diário pelo público em geral. Em particular, são necessários esforços de estabilização para polir o sistema de desenvolvimento em uma release de qualidade apropriada para uso em ambiente produtivo. Para resolver este conflito, o desenvolvimento continua em várias trilhas paralelas. A principal branch de desenvolvimento é a <emphasis>HEAD</emphasis> ou <emphasis>trunk</emphasis> da nossa árvore do Subversion, conhecida como <quote>FreeBSD-CURRENT</quote> ou <quote>-CURRENT</quote>  quando  abreviado.</para>

      <para>Um conjunto de branches mais estáveis é mantido, e é conhecido como <quote>FreeBSD-STABLE</quote> ou <quote>-STABLE</quote> na forma abreviada. Todas as branchs ficam em um repositório principal do Subversion mantido pelo Projeto FreeBSD. O FreeBSD-CURRENT é a <quote>vanguarda do desenvolvimento tecnológico</quote> do FreeBSD, pelo qual todas as novas alterações entram no sistema pela primeira vez. O FreeBSD-STABLE é a branch de desenvolvimento a partir do qual as releases principais são feitas. Mudanças entram nesta branch em um ritmo diferente, e com a suposição geral de que elas foram primeiro para o FreeBSD-CURRENT e foram exaustivamente testadas por nossa comunidade de usuários.</para>

      <para>O termo <emphasis>stable</emphasis> no nome da branch refere-se à estabilidade presumida da Interface Binária da Aplicação (ABI), que é prometida pelo projeto. Isso significa que um aplicativo de usuário compilado em uma versão mais antiga do sistema da mesma branch funciona em um sistema mais novo da mesma branch. A estabilidade do ABI melhorou muito em relação às versões anteriores. Na maioria dos casos, os binários dos sistemas <emphasis>STABLE</emphasis> mais antigos são executados sem modificações em sistemas mais recentes, incluindo o <emphasis>HEAD</emphasis>, assumindo que as interfaces de gerenciamento do sistema não são usadas.</para>

      <para>No período intermediário entre as versões, snapshots semanais são construídos automaticamente pelas máquinas de build do Projeto FreeBSD e disponibilizados para download em <systemitem>ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/</systemitem>. A ampla disponibilidade de snapshots binários e a tendência da nossa comunidade de usuários para acompanhar o desenvolvimento do -STABLE com o Subversion e <quote><command>make</command> <buildtarget>buildworld</buildtarget></quote> <footnote>
	<simpara><link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/handbook/makeworld.html">Re-construindo o "mundo"</link></simpara></footnote> ajuda a manter o FreeBSD-STABLE em uma condição muito confiável, mesmo antes que as atividades de garantia de qualidade aumentem na proximidade de um grande lançamento.</para>

      <para>Além dos snapshots de instalação no formato ISO, imagens semanais de máquinas virtuais também são fornecidas para uso com o <application>VirtualBox</application>, o <application>qemu</application> ou outros softwares populares de emulação. As imagens de máquinas virtuais podem ser baixadas em <systemitem>ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/VM-IMAGES/</systemitem>.</para>

      <para>As imagens das máquinas virtuais tem aproximadamente 150MB compactadas com o <citerefentry> <refentrytitle>xz</refentrytitle><manvolnum>1</manvolnum></citerefentry> e contêm um sistema de arquivos esparso de 10GB quando atachado a uma máquina virtual.</para>

      <para>Relatórios de bugs e solicitações de recursos são enviados continuamente pelos usuários durante todo o ciclo da release. Os relatórios de problemas são inseridos em nosso banco de dados do <application>Bugzilla</application> por meio da interface da Web disponibilizada em <uri xlink:href="https://www.freebsd.org/support/bugreports.html">https://www.freebsd.org/support/bugreports.html</uri>.</para>

      <para>Para atender nossos usuários mais conservadores, versões individuais foram introduzidas com o FreeBSD 4.3. Estas branchs de versões são criadas pouco antes de uma liberação final ser feita. Após o lançamento, somente as correções e adições de segurança mais críticas são aplicadas na branch da versão. Além das atualizações do código fonte via Subversion, patchkits binários estão disponíveis para manter os sistemas nas branchs <emphasis>releng/<replaceable>X</replaceable>.<replaceable>Y</replaceable></emphasis> atualizadas.</para>

      <sect2>
	<title>O que Este Artigo Descreve</title>

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

	<variablelist>
	  <varlistentry>
	    <term><xref linkend="release-proc"/></term>

	    <listitem>
	      <para>As diferentes fases do processo de engenharia de release que levam à criação do sistema atual.</para>
	    </listitem>
	  </varlistentry>

	  <varlistentry>
	    <term><xref linkend="release-build"/></term>

	    <listitem>
	      <para>O processo de criação atual.</para>
	    </listitem>
	  </varlistentry>

	  <varlistentry>
	    <term><xref linkend="extensibility"/></term>

	    <listitem>
	      <para>Como o release base pode ser estendido por terceiros.</para>
	    </listitem>
	  </varlistentry>

	  <varlistentry>
	    <term><xref linkend="lessons-learned"/></term>

	    <listitem>
	      <para>Algumas das lições aprendidas através do lançamento do FreeBSD 4.4.</para>
	    </listitem>
	  </varlistentry>

	  <varlistentry>
	    <term><xref linkend="future"/></term>

	    <listitem>
	      <para>Direções futuras de desenvolvimento.</para>
	    </listitem>
	  </varlistentry>
	</variablelist>
      </sect2>
    </sect1>

<!-- Release Process -->
    <sect1 xml:id="release-proc">
      <title>Processos de Release (Versão) </title>

      <para>Novas versões do FreeBSD são liberadas a partir da branch -STABLE em intervalos de aproximadamente quatro meses. O processo de release do FreeBSD começa a se desenhar cerca de 70-80 dias antes da data de lançamento prevista, quando o engenheiro de versão envia um email para as listas de discussão de desenvolvimento para lembrar aos desenvolvedores que eles só têm 15 dias para integrar novas alterações antes do congelamento de código. Durante esse tempo, muitos desenvolvedores executam o que ficou conhecido como <quote>MFC sweeps</quote>.</para>

      <para><acronym>MFC</acronym> significa <quote>Merge From CURRENT</quote> e descreve o processo de fusão de uma alteração testada de nossa branch de desenvolvimento -CURRENT com a nossa branch -STABLE. A política do projeto requer que qualquer mudança seja aplicada pela primeira vez ao trunk, e aplicada às branches -STABLE após testes externos suficientes serem feitos pelos usuários no -CURRENT (espera-se que os desenvolvedores testem extensivamente a mudança antes de enviarem a mesma para o -CURRENT, mas é impossível para uma pessoa  exercer todos os usos de um sistema operacional de propósito geral). O período mínimo de MFC é de 3 dias, que normalmente é usado apenas para correções de bugs triviais ou críticas.</para>

      <sect2>
	<title>Revisão de código</title>

	<para>Sessenta dias antes do lançamento previsto, o repositório de código entra um <quote>congelamento de código</quote>. Durante esse tempo, todos os commits para a branch -STABLE devem ser aprovados pela equipe de engenharia de release (versão) <email>re@FreeBSD.org</email>. O processo de aprovação é tecnicamente aplicado por um "pre-commit hook". Os tipos de alterações permitidos durante esse período incluem:</para>

	<itemizedlist>
	  <listitem>
	    <para>Correções de bugs.</para>
	  </listitem>

	  <listitem>
	    <para>Atualizações de documentação.</para>
	  </listitem>

	  <listitem>
	    <para>Correções relacionadas à segurança de qualquer tipo.</para>
	  </listitem>

	  <listitem>
	    <para>Pequenas alterações nos drivers de dispositivos, como a adição de novos IDs de dispositivos.</para>
	  </listitem>

	  <listitem>
	    <para>Atualizações de driver dos fornecedores.</para>
	  </listitem>

	  <listitem>
	    <para>Qualquer mudança adicional que a equipe de engenharia de release julgue justificada, dado o risco potencial.</para>
	  </listitem>
	</itemizedlist>

	<para>Logo após o início do congelamento de código, uma imagem <emphasis>BETA1</emphasis> é criada e liberada para testes generalizados. Durante o congelamento de código, pelo menos uma imagem beta ou um candidato a versão é lançado a cada duas semanas até que a versão final esteja pronta. Durante os dias que antecedem a versão final, a equipe de engenharia de release está em constante comunicação com a equipe de segurança, os mantenedores de documentação e os mantenedores de ports para garantir que todos os diferentes componentes necessários para uma versão bem-sucedida estejam disponíveis.</para>

	<para>Após a qualidade das imagens BETA ser satisfatória o suficiente, e nenhuma mudança grande e potencialmente arriscada estar planejada, a branch release é criada e as imagens <emphasis>Release Candidate</emphasis> (RC) são construídas a partir da branch release, ao invés das Imagens BETA serem construidas da branch STABLE. Além disso, o congelamento na branch STABLE é suspenso e a branch de release entra em um <quote>congelamento de código rígido</quote>, onde fica muito mais difícil justificar novas alterações no sistema, a menos que envolva uma correção séria de bug ou um problema de segurança.</para>
      </sect2>

      <sect2>
	<title>Checklist Final para uma Release</title>

	<para>Quando várias imagens BETA já tiverem sido disponibilizadas para testes generalizados e todos os principais problemas tiverem sido resolvidos, o <quote>polimento</quote> da versão final pode começar.</para>

	<sect3 xml:id="rel-branch">
	  <title>Criação da Branch (Ramificação) da Release (Versão)</title>

	  <note>
	    <para>Em todos os exemplos abaixo, <literal>$FSVN</literal> refere-se ao local do repositório Subversion do FreeBSD, <literal>svn+ssh://svn.FreeBSD.org/base/</literal>.</para>
	  </note>

	  <para>O layout das branchs do FreeBSD no Subversion é descrito no <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/articles/committers-guide/subversion-primer.html#subversion-primer-base-layout">Guia do Commiter</link>. O primeiro passo na criação de uma branch é identificar a revisão do código fonte do  <literal>stable/<replaceable>X</replaceable></literal>, a partir do qual você deseja criar a nova <emphasis>branch</emphasis>.</para>

	  <screen><prompt>#</prompt> <userinput>svn log -v $FSVN/stable/9</userinput></screen>

	  <para>O próximo passo é criar a <emphasis>branch da release</emphasis></para>

	  <screen><prompt>#</prompt> <userinput>svn cp $FSVN/stable/9@REVISION $FSVN/releng/9.2</userinput></screen>

	  <para>Esta branch pode ser obtida com:</para>

	  <screen><prompt>#</prompt> <userinput>svn co $FSVN/releng/9.2 src</userinput></screen>

      <note>
	<para>A criação das tags da branch <literal>releng</literal> e de <literal>release</literal> é feita pela <link xlink:href="@@URL_RELPREFIX@@/administration.html#t-re">Equipe de Engenharia de Release</link>.</para>
      </note>

      <mediaobject><imageobject> <imagedata fileref="branches-head" align="center"/> </imageobject> <textobject><phrase>Branch de Desenvolvimento do FreeBSD</phrase></textobject></mediaobject>

      <mediaobject><imageobject> <imagedata fileref="branches-releng3" align="center"/> </imageobject> <textobject><phrase>Branch FreeBSD 3.x STABLE</phrase></textobject></mediaobject>

      <mediaobject><imageobject> <imagedata fileref="branches-releng4" align="center"/> </imageobject> <textobject> <phrase>Branch FreeBSD 4.x STABLE</phrase></textobject></mediaobject>

      <mediaobject><imageobject> <imagedata fileref="branches-releng5" align="center"/> </imageobject> <textobject><phrase>Branch FreeBSD 5.x STABLE</phrase></textobject></mediaobject>

      <mediaobject><imageobject> <imagedata fileref="branches-releng6" align="center"/></imageobject><textobject><phrase>Branch FreeBSD 6.x STABLE</phrase></textobject></mediaobject>

      <mediaobject><imageobject> <imagedata fileref="branches-releng7" align="center"/></imageobject><textobject><phrase>Branch FreeBSD 7.x STABLE</phrase></textobject></mediaobject>

      <mediaobject><imageobject> <imagedata fileref="branches-releng8" align="center"/> </imageobject><textobject><phrase>Branch FreeBSD 8.x STABLE</phrase></textobject></mediaobject>

      <mediaobject><imageobject> <imagedata fileref="branches-releng9" align="center"/> </imageobject> <textobject><phrase>Branch FreeBSD 9.x STABLE</phrase></textobject></mediaobject>
    </sect3>

    <sect3 xml:id="versionbump">
      <title>Incrementando o número da versão</title>

      <para>Antes que a versão final possa ser marcada, construída e lançada, os seguintes arquivos precisam ser modificados para refletir a versão correta do FreeBSD:</para>

      <itemizedlist>
	<listitem>
	  <para><filename>doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml</filename></para>
	</listitem>

	<listitem>
	  <para><filename>doc/en_US.ISO8859-1/books/porters-handbook/book.xml</filename></para>
	</listitem>

	<listitem>
	  <para><filename>doc/en_US.ISO8859-1/htdocs/cgi/ports.cgi</filename></para>
	</listitem>

	<listitem>
	  <para><filename>ports/Tools/scripts/release/config</filename></para>
	</listitem>

	<listitem>
	  <para><filename>doc/share/xml/freebsd.ent</filename></para>
	</listitem>

	<listitem>
	  <para><filename>src/Makefile.inc1</filename></para>
	</listitem>

	<listitem>
	  <para><filename>src/UPDATING</filename></para>
	</listitem>

	<listitem>
	  <para><filename>src/gnu/usr.bin/groff/tmac/mdoc.local</filename></para>
	</listitem>

	<listitem>
	  <para><filename>src/release/Makefile</filename></para>
	</listitem>

	<listitem>
	  <para><filename>src/release/doc/en_US.ISO8859-1/share/xml/release.dsl</filename></para>
	</listitem>

	<listitem>
	  <para><filename>src/release/doc/share/examples/Makefile.relnotesng</filename></para>
	</listitem>

	<listitem>
	  <para><filename>src/release/doc/share/xml/release.ent</filename></para>
	</listitem>

	<listitem>
	  <para><filename>src/sys/conf/newvers.sh</filename></para>
	</listitem>

	<listitem>
	  <para><filename>src/sys/sys/param.h</filename></para>
	</listitem>

	<listitem>
	  <para><filename>src/usr.sbin/pkg_install/add/main.c</filename></para>
	</listitem>

	<listitem>
	  <para><filename>doc/en_US.ISO8859-1/htdocs/search/opensearch/man.xml</filename></para>
	</listitem>
      </itemizedlist>

      <para>As notas de versão e os arquivos de errata também precisam ser ajustados para a nova versão (na branch (ramificação) da release) e truncados apropriadamente (na branch stable/current):</para>

      <itemizedlist>
	<listitem>
	  <para><filename>src/release/doc/en_US.ISO8859-1/relnotes/common/new.xml</filename></para>
	</listitem>

	<listitem>
	  <para><filename>src/release/doc/en_US.ISO8859-1/errata/article.xml</filename></para>
	</listitem>
      </itemizedlist>

      <para>O <application>Sysinstall</application> deve ser atualizado para exibir o número de ports disponíveis e a quantidade de espaço em disco necessária para a Coleção de Ports. <footnote>
	  <simpara>Coleção de Ports do FreeBSD <uri xlink:href="https://www.FreeBSD.org/ports">https://www.FreeBSD.org/port</uri></simpara>
	</footnote> Esta informação é atualmente mantida em <filename>src/usr.sbin/bsdinstall/dist.c</filename>.</para>

      <para>Após a release ter sido construida, vários arquivos devem ser atualizados para anunciar a versão para o mundo. Esses arquivos são relativos a <literal>head/</literal> dentro da árvore <literal>doc/</literal> do subversion.</para>

      <itemizedlist>
	<listitem>
	  <para><filename>share/images/articles/releng/branches-releng<replaceable>X</replaceable>.pic</filename></para>
	</listitem>

	<listitem>
	  <para><filename>head/share/xml/release.ent</filename></para>
	</listitem>

	<listitem>
	  <para><filename>en_US.ISO8859-1/htdocs/releases/*</filename></para>
	</listitem>

	<listitem>
	  <para><filename>en_US.ISO8859-1/htdocs/releng/index.xml</filename></para>
	</listitem>

	<listitem>
	  <para><filename>share/xml/news.xml</filename></para>
	</listitem>
      </itemizedlist>

      <para>Além disso, atualize o arquivo da <quote>Árvore Genealógica do BSD</quote>:</para>

      <itemizedlist>
	<listitem>
	  <para><filename>src/share/misc/bsd-family-tree</filename></para>
	</listitem>
      </itemizedlist>
    </sect3>

    <sect3>
      <title>Criando a Tag de Release</title>

      <para>Quando a versão final estiver pronta, o seguinte comando criará a tag <literal>release/9.2.0</literal>.</para>

      <screen><prompt>#</prompt> <userinput>svn cp $FSVN/releng/9.2 $FSVN/release/9.2.0</userinput></screen>

      <para>Os gerentes de Documentação e do Ports são responsáveis por marcar suas respectivas árvores com a tag <literal>tags/RELEASE_9_2_0</literal>.</para>

      <sidebar>
	<para>Quando o comando <command>svn cp</command> do Subversion é usado para criar uma <emphasis>tag de versão</emphasis>, isso identifica o código fonte em um ponto específico no tempo. Criando tags, nós garantimos que futuros construtores de versões sempre poderão usar exatamente o mesmo código fonte que usamos para criar as releases oficiais do Projeto FreeBSD.</para>
      </sidebar>
    </sect3>
  </sect2>
</sect1>

<!-- Release Building -->
<sect1 xml:id="release-build">
  <title>Construção da Release (Versão)</title>

  <para>As <quote>releases</quote> do FreeBSD podem ser construídas por qualquer pessoa com uma máquina rápida e acesso a um repositório de código-fonte. (Isso deveria ser todo mundo, já que oferecemos acesso ao Subversion! Veja a seção sobre <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/handbook/svn.html">Subversion</link> no Handbook para detalhes.)  O <emphasis>único</emphasis> requisito especial é que o dispositivo <citerefentry><refentrytitle>md</refentrytitle><manvolnum>4</manvolnum></citerefentry> esteja disponível. Se o dispositivo não estiver carregado em seu kernel, então o módulo do kernel deve ser carregado automaticamente quando o <citerefentry><refentrytitle>mdconfig</refentrytitle><manvolnum>8</manvolnum></citerefentry> for executado durante a fase de criação da mídia de boot. Todas as ferramentas necessárias para construir uma release estão disponíveis no repositório Subversion em <filename>src/release</filename>. Essas ferramentas visam fornecer uma maneira consistente de construir versões do FreeBSD. Uma release completa pode ser construída com apenas um único comando, incluindo a criação de imagens <acronym>ISO</acronym> adequadas para gravação em CD-ROM ou DVD e um diretório para instalação por FTP. A pagina de manual <citerefentry><refentrytitle>release</refentrytitle><manvolnum>7</manvolnum></citerefentry> documenta completamente o script <command>src/release/generate-release.sh</command> que é usado para construir uma release. O <command>generate-release.sh</command> é um invólucro em torno do target do Makefile: <command>make release</command>.</para>

  <sect2>
    <title>Construindo uma Release (Versão)</title>

    <para>A página de manual <citerefentry><refentrytitle>release</refentrytitle><manvolnum>7</manvolnum></citerefentry> documenta os comandos exatos necessários para construir uma Release do FreeBSD. As seguintes sequências de comandos podem construir uma versão 9.2.0:</para>

    <screen><prompt>#</prompt> <userinput>cd /usr/src/release</userinput>
<prompt>#</prompt> <userinput>sh generate-release.sh release/9.2.0 /local3/release</userinput></screen>

    <para>Depois de executar esses comandos, todos os arquivos preparados da versão estarão disponíveis no diretório <filename>/local3/release/R</filename>.</para>

    <para>O release <filename>Makefile</filename> pode ser dividido em várias etapas distintas.</para>

    <itemizedlist>
      <listitem>
	<para>Criação de um ambiente de sistema limpo em uma hierarquia de diretório separada com <quote><command>make installworld</command></quote>.</para>
      </listitem>

      <listitem>
	<para>Checkout do Subversion de uma versão limpa do código fonte do sistema, da documentação e e da coleção de ports na hierarquia de build do release.</para>
      </listitem>

      <listitem>
	<para>Popula o <filename>/etc</filename> e o <filename>/dev</filename> no ambiente chrooted (Processo de transferir o diretório root para outro lugar).</para>
      </listitem>

      <listitem>
	<para>Faz chroot na hierarquia de build (construção) da release, para tornar mais difícil para o ambiente externo corromper essa construção.</para>
      </listitem>

      <listitem>
	<para>Execução do comando <command>make world</command> no ambiente chrooted.</para>
      </listitem>

      <listitem>
	<para>Compilação dos binários relacionados ao Kerberos.</para>
      </listitem>

      <listitem>
	<para>Compilação do kernel <filename>GENERIC</filename>.</para>
      </listitem>

      <listitem>
	<para>Criação uma árvore de diretórios temporários onde as distribuições binárias serão compiladas e empacotadas.</para>
      </listitem>

      <listitem>
	<para>Compilação e instalação do toolchain necessário para converter o fonte da documentação (SGML) em HTML e demais documentos de texto que acompanharão a versão.</para>
      </listitem>

      <listitem>
	<para>Compilação e instalação da documentação propriamente dita (manuais do usuário, tutoriais, notas de versão, listas de compatibilidade de hardware e assim por diante).</para>
      </listitem>

      <listitem>
	<para>Empacotamento dos tarballs de distribuição dos binários e fontes.</para>
      </listitem>

      <listitem>
	<para>Criação da hierarquia de instalação por FTP.</para>
      </listitem>

      <listitem>
	<para><emphasis>(opcionalmente)</emphasis> Criação das imagens ISO para mídia de CDROM/DVD.</para>
      </listitem>
    </itemizedlist>

    <para>Para obter maiores informações sobre a infraestrutura de criação de versões, consulte <citerefentry><refentrytitle>release</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>

    <note>
      <para>É importante remover qualquer configuração específica do seu servidor do <filename>/etc/make.conf</filename>. Por exemplo, seria imprudente distribuir binários que foram compilados em um sistema com <varname>CPUTYPE</varname> configurado para um processador específico.</para>
    </note>
  </sect2>

  <sect2>
    <title>Software Contribuído (<quote>ports</quote>)</title>

    <para>A <link xlink:href="https://www.FreeBSD.org/ports">Coleção de Ports do FreeBSD</link> é uma coleção de mais de 24.000 pacotes de software de terceiros disponíveis para o FreeBSD. A Equipe de Gerenciamento de Ports <email>portmgr@FreeBSD.org</email> é responsável por manter uma árvore de ports consistente que pode ser usada para criar os pacotes binários que acompanham as releases oficiais do FreeBSD.</para>
  </sect2>

  <sect2>
    <title>ISOs das Releases (Versões) </title>

    <para>Começando no FreeBSD 4.4, o Projeto FreeBSD decidiu liberar todas as quatro imagens ISO que eram vendidas anteriormente nas distribuições <quote>oficiais</quote> em CDROM pela <emphasis>BSRi/Wind River Systems/FreeBSD Mall</emphasis>. Cada um dos quatro discos deve conter um arquivo <filename>README.TXT</filename> que explica o conteúdo do disco, um arquivo <filename>CDROM.INF</filename> que fornece metadados do disco para que o <citerefentry><refentrytitle>bsdinstall</refentrytitle><manvolnum>8</manvolnum></citerefentry> possa validar e usar o conteúdo, e um arquivo <filename>filename.txt</filename> que fornece um manifesto para o disco. Este <emphasis>manifesto</emphasis> pode ser criado com um simples comando:</para>

    <screen>/stage/cdrom<prompt>#</prompt> <userinput>find . -type f | sed -e 's/^\.\///' | sort &gt; filename.txt</userinput></screen>

    <para>Os requisitos específicos de cada CD são descritos abaixo.</para>

    <sect3>
      <title>Disco 1</title>

      <para>O primeiro disco é quase completamente criado por <command>make release</command>. As únicas alterações que devem ser feitas no diretório <filename>disc1</filename> são a adição de um diretório <filename>tools</filename> e tantos pacotes de software de terceiros quanto couberem no disco. O diretório <filename>tools</filename> contém software que permite aos usuários criar disquetes de instalação a partir de outros sistemas operacionais. Esse disco deve ser inicializado para que os usuários dos PCs modernos não precisem criar disquetes de instalação.</para>

      <para>Se um kernel customizado do FreeBSD precisa ser incluído, então o <citerefentry><refentrytitle>bsdinstall</refentrytitle><manvolnum>8</manvolnum></citerefentry> e o <citerefentry><refentrytitle>release</refentrytitle><manvolnum>7</manvolnum></citerefentry> deve ser atualizado para incluir instruções de instalação. O código relevante está contido em <filename>src/release</filename> e <filename>src/usr.sbin/bsdinstall</filename>. Especificamente, os arquivos <filename>src/release/Makefile</filename>, <filename>dist.c</filename>, <filename>dist.h</filename>, <filename>menus.c</filename> , <filename>install.c</filename>, e <filename>Makefile</filename> precisarão ser atualizados em <filename>src/usr.sbin/bsdinstall</filename>. Opcionalmente, você pode escolher atualizar o <filename>bsdinstall.8</filename>.</para>
    </sect3>

    <sect3>
      <title>Disco 2</title>

      <para>O segundo disco também é largamente criado por <command>make release</command>. Este disco contém um <quote>live filesystem</quote> que pode ser usado por <citerefentry><refentrytitle>bsdinstall</refentrytitle><manvolnum>8</manvolnum></citerefentry> para solucionar problemas de instalação do FreeBSD. Este disco deve ser inicializável e também deve conter uma cópia compactada do repositório CVS no diretório <filename>CVSROOT</filename> e demos de software comercial no diretório <filename>commerce</filename>.</para>
    </sect3>

    <sect3>
      <title>Suporte para vários volumes</title>

      <para>O <application>Sysinstall</application> suporta a instalação de pacotes a partir de vários volumes. Isso requer que cada disco tenha um arquivo <filename>INDEX</filename> contendo todos os pacotes em todos os volumes de um conjunto, junto com um campo extra que indica em qual volume esse pacote específico está. Cada volume no conjunto também deve ter a variável <literal>CD_VOLUME</literal> definida no arquivo <filename>cdrom.inf</filename> para que o bsdinstall possa informar qual volume é qual. Quando um usuário tentar instalar um pacote que não esteja no disco atual, o bsdinstall solicitará que o usuário insira o disco apropriado.</para>
    </sect3>
  </sect2>
</sect1>

<!-- Distribution -->
<sect1 xml:id="distribution">
  <title>Distribuição</title>

  <sect2 xml:id="dist-ftp">
    <title>Sites FTP</title>

    <para>Quando a release for totalmente testada e empacotada para distribuição, o site FTP principal deverá ser atualizado. Os sites de FTP públicos oficiais do FreeBSD são todos espelhos de um servidor principal que está acessível somente a outros sites FTP. Este site é conhecido como <systemitem>ftp-master</systemitem>. Quando a release estiver pronta, os seguintes arquivos devem ser modificados no <systemitem>ftp-master</systemitem>:</para>

    <variablelist>
      <varlistentry>
	<term><filename>/pub/FreeBSD/releases/<replaceable>arch</replaceable>/<replaceable>X.Y</replaceable>-RELEASE/</filename></term>
	<listitem>
	  <para>O diretório FTP instalável como saída de <command>make release</command>.</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><filename>/pub/FreeBSD/ports/<replaceable>arch</replaceable>/packages-<replaceable>X.Y</replaceable>-release/</filename></term>
	<listitem>
	  <para>O pacote completo criado para esta versão.</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><filename>/pub/FreeBSD/releases/<replaceable>arch</replaceable>/<replaceable>X.Y</replaceable>-RELEASE/tools</filename></term>
	<listitem>
	  <para>Um link simbólico para <filename>../../../tools</filename>.</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><filename>/pub/FreeBSD/releases/<replaceable>arch</replaceable>/<replaceable>X.Y</replaceable>-RELEASE/packages</filename></term>
	<listitem>
	  <para>Um link simbólico para <filename>../../../ports/<replaceable>arch</replaceable>/packages-<replaceable>X.Y</replaceable>-release</filename>.</para>
	</listitem>
      </varlistentry>

      <varlistentry>
	<term><filename>/pub/FreeBSD/releases/<replaceable>arch</replaceable>/ISO-IMAGES/<replaceable>X.Y</replaceable>/<replaceable>X.Y</replaceable>-RELEASE-<replaceable>arch</replaceable>-*.iso</filename></term>
	<listitem>
	  <para>As imagens ISO. O <quote>*</quote> é o <filename>disc1</filename>, <filename> disc2 </filename>, etc. Somente se houver um <filename>disc1</filename> e houver um CD alternativo para o primeiro disco de instalação  (por exemplo, uma instalação simplificada sem sistema de janelas) também pode haver um <filename>mini</filename>.</para>
	</listitem>
      </varlistentry>
    </variablelist>

    <para>Para mais informações sobre a arquitetura do sistema de espelhamento dos sites de FTP para distribuição do FreeBSD, por favor veja o artigo <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/articles/hubs/">Espelhando o FreeBSD</link>.</para>

    <para>Pode levar de muitas horas a dois dias após a atualização do <systemitem>ftp-master</systemitem> antes que a maioria dos sites de FTP da camada 1 tenham o novo software, dependendo se um conjunto de pacotes foi ou não carregado ao mesmo tempo. É imperativo que os engenheiros de release coordenem com os <link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/mirror-announce">administradores dos sites espelho do FreeBSD</link> antes de anunciar a disponibilidade geral de novo software nos sites FTP. Idealmente, o pacote da release deve ser carregado pelo menos quatro dias antes do dia de lançamento. Os bits da release devem ser carregados entre 24 e 48 horas antes do horário de lançamento planejado com as permissões de arquivo <quote>other</quote> desativadas. Isso permitirá que os sites espelho façam o download, mas o público em geral não poderá baixá-los dos sites espelho. Um e-mail deve ser enviado para a lista dos <link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/mirror-announce">administradores do site espelho do FreeBSD</link> no momento em que os bits da release forem publicados, informando que a release foi preparada e informando o horário em que os sites espelho devem começar a permitir o acesso. Certifique-se de incluir um fuso horário com a hora, por exemplo, torná-lo relativo ao GMT.</para>
  </sect2>

  <sect2 xml:id="dist-cdrom">
    <title>Replicação do CD-ROM</title>

    <para>Em breve: Dicas para enviar ISOs do FreeBSD para um replicador e medidas de garantia de qualidade a serem tomadas.</para>
  </sect2>

</sect1>

<!-- Extensibility -->
<sect1 xml:id="extensibility">
  <title>Extensibilidade</title>

  <para>Embora o FreeBSD forme um sistema operacional completo, não há nada que force você a usar o sistema exatamente como o empacotamos para distribuição. Tentamos projetar o sistema para ser o mais extensível possível, de modo que ele possa servir como uma plataforma na qual outros produtos comerciais possam ser construídos. A única <quote>regra</quote> que temos sobre isso é que se você for distribuir o FreeBSD com mudanças não triviais, nós encorajamos você a documentar suas melhorias! A comunidade do FreeBSD só pode ajudar a suportar usuários do software que fornecemos. Nós certamente encorajamos a inovação na forma de ferramentas avançadas de instalação e administração, por exemplo, mas você não esperar que respondamos perguntas sobre isso.</para>

  <sect2>
    <title>Usando o script <command>bsdinstall</command></title>

    <para>A ferramenta de instalação e configuração do sistema FreeBSD, <citerefentry><refentrytitle>bsdinstall</refentrytitle><manvolnum>8</manvolnum></citerefentry>, pode ser programada para fornecer instalações automatizadas para sites grandes. Essa funcionalidade pode ser usada em conjunto com <trademark class="registered">Intel</trademark> PXE <footnote>
	<simpara><uri xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/handbook/network-pxe-nfs.html">@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/handbook/network-pxe-nfs.html</uri></simpara>
      </footnote> para inicializar sistemas da rede.</para>
  </sect2>
</sect1>

<!-- Lessons Learned -->
<sect1 xml:id="lessons-learned">
  <title>Lições Aprendidas do FreeBSD 4.4</title>

  <para>O processo de engenharia de release do 4.4 começou formalmente em 1º de agosto de 2001. Após essa data, todos os commits da branch <literal>RELENG_4</literal> do FreeBSD tiveram que ser explicitamente aprovados pela Equipe de Engenharia de Release <email>re@FreeBSD.org</email>. O primeiro release candidate para a arquitetura x86 foi lançado em 16 de agosto, seguido por mais 4 candidatos a versão que antecederam a versão final em 18 de setembro. O agente de segurança esteve muito envolvido na última semana do processo, pois vários problemas de segurança foram encontrados nos candidatos anteriores. Um total de mais de <emphasis>500</emphasis> e-mails foram enviados para a Equipe de Engenharia de Release <email>re@FreeBSD.org</email> em pouco mais de um mês.</para>

  <para>Nossa comunidade de usuários deixou bem claro que a segurança e a estabilidade de uma versão do FreeBSD não devem ser sacrificadas por quaisquer prazos auto-impostos ou datas-alvo de lançamento. O projeto FreeBSD cresceu tremendamente ao longo de sua existência e a necessidade de procedimentos padronizados de engenharia de versões nunca foi tão aparente. Isso se tornará ainda mais importante à medida que o FreeBSD for portado para novas plataformas.</para>
</sect1>

<!-- Future Directions -->
<sect1 xml:id="future">
  <title>Direções futuras</title>

  <para>É imperativo que nossas atividades de engenharia de release sejam escaladas com nossa crescente base de usuários. Nessa linha, estamos trabalhando muito para documentar os procedimentos envolvidos na produção de versões do FreeBSD.</para>

  <itemizedlist>
    <listitem>
      <para><emphasis>Paralelismo</emphasis> - Algumas partes da compilação da release são, na verdade, <quote>embaraçosamente paralelas</quote>. A maioria das tarefas é muito intensiva em I/O, portanto, ter várias unidades de disco de alta velocidade é realmente mais importante do que usar vários processadores para acelerar o processo do <command>make release</command>. Se vários discos forem usados para hierarquias diferentes no ambiente <citerefentry><refentrytitle>chroot</refentrytitle><manvolnum>2</manvolnum></citerefentry>, o CVS checkout das árvores do <filename>ports</filename> e do <filename>doc</filename> podem estar acontecendo simultaneamente como o <command>make world</command> em outro disco. Usar uma solução <acronym>RAID</acronym> (hardware ou software) pode diminuir significativamente o tempo de compilação geral.</para>
    </listitem>

    <listitem>
      <para><emphasis>Releases cross-building</emphasis> - Criação do release IA-64 ou Alpha em hardware x86? Use o comando <command>make TARGET=ia64 release</command>.</para>
    </listitem>

    <listitem>
      <para><emphasis>Teste de regressão</emphasis> - Precisamos de melhores testes automatizados para o FreeBSD.</para>
    </listitem>

    <listitem>
      <para><emphasis>Ferramentas de instalação</emphasis> - Nosso programa de instalação há muito tempo ultrapassou à sua expectativa de vida útil. Vários projetos estão em desenvolvimento para fornecer um mecanismo de instalação mais avançado. O projeto libh era um desses projetos que visava fornecer um novo e inteligente framework de pacotes e um programa de instalação GUI.</para>
    </listitem>
  </itemizedlist>

</sect1>

<!-- Acknowledgements -->
<sect1 xml:id="ackno">
  <title>Agradecimentos</title>

  <para>Eu gostaria de agradecer a Jordan Hubbard por me dar a oportunidade de assumir algumas das responsabilidades de engenharia de release do FreeBSD 4.4 e também por todo o seu trabalho ao longo dos anos fazendo do FreeBSD o que é hoje. É claro quea Release não teria sido possível sem todo o trabalho relacionado a release feito por Satoshi Asami <email>asami@FreeBSD.org</email>, Steve Price <email>steve@FreeBSD.org</email>, Bruce A. Mah <email>bmah@FreeBSD.org</email>, Nik Clayton <email>nik@FreeBSD.org</email>, David O'Brien <email>obrien@FreeBSD.org</email>, Kris Kennaway <email>kris@FreeBSD.org</email>, John Baldwin <email>jhb@FreeBSD.org</email> e o resto da comunidade de desenvolvimento do FreeBSD. Eu também gostaria de agradecer a Rodney Grimes <email>rgrimes@FreeBSD.org</email>, Poul-Henning Kamp <email>phk@FreeBSD.org</email>, e outros que trabalharam nas ferramentas de engenharia de release nos  primeiros dias do FreeBSD. Este artigo foi influenciado por documentos de engenharia de release do CSRG <footnote>
      <simpara>Marshall Kirk McKusick, Michael J. Karels e Keith Bostic: <link xlink:href="http://docs.FreeBSD.org/44doc/papers/releng.html"> <emphasis>A Engenharia de Release do 4.3BSD</emphasis></link></simpara>
    </footnote>, o Projeto NetBSD, <footnote>
      <simpara>Documentação do desenvolvedor do NetBSD: Engenharia de Release <uri xlink:href="http://www.NetBSD.org/developers/releng/index.html">http://www.NetBSD.org/developers/releng/index.html</uri></simpara>
    </footnote>, e as notas de processo de engenharia de release propostas por John Baldwin. <footnote>
      <simpara>Proposta de engenharia de Release do FreeBSD de John Baldwin <uri xlink:href="https://people.FreeBSD.org/~jhb/docs/releng.txt">https://people.FreeBSD.org/~jhb/docs/releng.txt</uri></simpara>
      </footnote></para></sect1></article>