2. FreeBSD Doc
  3. books_dev-model
  4. Portuguese (Brazil)
  5. Translate

Translation

(itstool) path: section/para
Following and including, 4.3-RELEASE<_:footnote-1/>, when a minor release has been made, it becomes a <quote>security branch</quote>. This is meant for organisations that do not want to follow the -STABLE branch and the potential new/changed features it offers, but instead require an absolutely stable environment, only updating to implement security updates. <_:footnote-2/>
399/3760
Context English Portuguese (Brazil) State
3.0 Current (development branch)
Releng 3 branches: 3.0 Release to 3.5 Release, leading to 3.5.1 Release and the subsequent 3 Stable branch
4.0 Current (development branch)
3.1 Release
Releng 4 branches: 4.1 Release to 4.6 Release (and 4.6.2 Release), then 4.7 Release to 4.11 Release (all starting at 4.3 Release also leading to a Releng_4_n branch), and the subsequent 4 Release branch
5.0 Current (development branch)
4.0 Release
Releng 5 branches: 5.0 Release to 5.4 Release (all except 5.0 and 5.3 also leading to a Releng_5_n branch), and the subsequent 5 Release branch
6.0 Current (development branch)
5.3 Release
The latest -CURRENT version is always referred to as -CURRENT, while the latest -STABLE release is always referred to as -STABLE. In this figure, -STABLE refers to 4-STABLE while -CURRENT refers to 5.0-CURRENT following 5.0-RELEASE. <citation><xref linkend="freebsd-releng"/></citation> A última versão -CURRENT é sempre referida como -CURRENT, enquanto a versão mais recente -STABLE é sempre referida como -STABLE. Nessa figura, -STABLE se refere a 4-STABLE, enquanto -CURRENT refere-se a 5.0-CURRENT seguindo para 5.0-RELEASE. <citation><xref linkend="freebsd-releng"/></citation>
A <quote>major release</quote> is always made from the -CURRENT branch. However, the -CURRENT branch does not need to fork at that point in time, but can focus on stabilising. An example of this is that following 3.0-RELEASE, 3.1-RELEASE was also a continuation of the -CURRENT-branch, and -CURRENT did not become a true development branch until this version was released and the 3-STABLE branch was forked. When -CURRENT returns to becoming a development branch, it can only be followed by a major release. 5-STABLE is predicted to be forked off 5.0-CURRENT at around 5.3-RELEASE. It is not until 5-STABLE is forked that the development branch will be branded 6.0-CURRENT. Um <quote>lançamento principal</quote> é sempre feito a partir da branch -CURRENT. No entanto, a branch -CURRENT não precisa ser feito fork nesse momento, mas pode concentrar-se na estabilização. Um exemplo disso é que, após 3.0-RELEASE, 3.1-RELEASE também era uma continuação da branch -CURRENT, e -CURRENT não se tornou uma branch de desenvolvimento verdadeira até que esta versão fosse lançada e fosse feito o fork da branch 3-STABLE. Quando -CURRENT retorna para se tornar uma branch de desenvolvimento, ele só pode ser seguido por um lançamento principal. Prevê-se que seja feito o fork do 5-STABLE a partir da branch 5.0-CURRENT em torno da 5.3-RELEASE. Não é feito até que seja feito o fork da 5-STABLE, então a branch de desenvolvimento será marcada como 6.0-CURRENT.
A <quote>minor release</quote> is made from the -CURRENT branch following a major release, or from the -STABLE branch. Uma <quote>versão secundária</quote> é feita a partir da branch -CURRENT após uma versão principal ou da branch -STABLE.
The first release this actually happened for was 4.5-RELEASE, but security branches were at the same time created for 4.3-RELEASE and 4.4-RELEASE. A primeira versão onde isso aconteceu foi na 4.5-RELEASE, mas as branches de segurança foram criadas ao mesmo tempo para 4.3-RELEASE e 4.4-RELEASE.
There is a terminology overlap with respect to the word "stable", which leads to some confusion. The -STABLE branch is still a development branch, whose goal is to be useful for most people. If it is never acceptable for a system to get changes that are not announced at the time it is deployed, that system should run a security branch. Existe uma terminologia que se sobrepõe à palavra "stable (estável)", o que leva a alguma confusão. A branch -STABLE ainda é uma branch de desenvolvimento, cujo objetivo é ser útil para a maioria das pessoas. Se nunca for aceitável que um sistema obtenha alterações que não são anunciadas no momento em que é implantado, esse sistema deve executar uma branch de segurança.
Following and including, 4.3-RELEASE<_:footnote-1/>, when a minor release has been made, it becomes a <quote>security branch</quote>. This is meant for organisations that do not want to follow the -STABLE branch and the potential new/changed features it offers, but instead require an absolutely stable environment, only updating to implement security updates. <_:footnote-2/> Seguindo e incluindo, 4.3-RELEASE <_:footnote-1/>, quando uma liberação secundária foi feita, ela se torna uma <quote>branch de segurança</quote>. Isso se destina a organizações que não desejam seguir a branch -STABLE e os possíveis recursos novos/alterados que oferece, mas que exigem um ambiente absolutamente estável, atualizando apenas para implementar atualizações de segurança. <_:footnote-2/>
Each update to a security branch is called a <quote>patchlevel</quote>. For every security enhancement that is done, the patchlevel number is increased, making it easy for people tracking the branch to see what security enhancements they have implemented. In cases where there have been especially serious security flaws, an entire new release can be made from a security branch. An example of this is 4.6.2-RELEASE. Cada atualização para uma branch de segurança é chamada de <quote>patchlevel (à nível de correção)</quote>. Para cada aprimoramento de segurança que é feito, o número de patchlevel é aumentado, tornando mais fácil para as pessoas rastrearem a branch para ver quais melhorias de segurança implementaram. Nos casos em que houve falhas graves de segurança, uma nova versão inteira pode ser feita a partir de uma branch de segurança. Um exemplo disso é a 4.6.2-RELEASE.
Model summary Resumo do modelo
To summarise, the development model of FreeBSD can be seen as the following tree: Para resumir, o modelo de desenvolvimento do FreeBSD pode ser visto como a seguinte árvore:
The overall development model O modelo geral de desenvolvimento
_ external ref='freebsd-code-model' md5='__failed__' external ref='freebsd-code-model' md5='__failed__'
<imageobject><imagedata fileref="freebsd-code-model"/></imageobject> <textobject><_:literallayout-1/></textobject> <textobject> <phrase>Refer to paragraphs below for a screen-reader friendly version.</phrase> </textobject>
The tree of the FreeBSD development with ongoing development efforts and continuous integration. A árvore do desenvolvimento do FreeBSD com esforços contínuos de desenvolvimento e integração contínua.
The tree symbolises the release versions with major versions spawning new main branches and minor versions being versions of the main branch. The top branch is the -CURRENT branch where all new development is integrated, and the -STABLE branch is the branch directly below it. Below the -STABLE branch are old, unsupported versions. A árvore simboliza as versões de lançamento com versões principais gerando novas branchs principais e versões secundárias sendo versões da branch principal. A branch superior é a branch -CURRENT, onde todo o desenvolvimento novo é integrado, e a branch -STABLE é a branch diretamente abaixo dela.
Clouds of development efforts hang over the project where developers use the development models they see fit. The product of their work is then integrated into -CURRENT where it undergoes parallel debugging and is finally merged from -CURRENT into -STABLE. Security fixes are merged from -STABLE to the security branches. Nuvens de esforços de desenvolvimento pairam sobre o projeto, onde os desenvolvedores usam os modelos de desenvolvimento que eles acham adequados. O produto de seu trabalho é então integrado em -CURRENT, onde ele é depurado paralelamente e finalmente é feito o merge (aplicado o código) do -CURRENT na -STABLE. As correções de segurança são feitos os merges (aplicado os códigos) da -STABLE para as branches de segurança.
Hats Hats (Funções)
Many committers have a special area of responsibility. These roles are called hats. These hats can be either project roles, such as public relations officer, or maintainer for a certain area of the code. Because this is a project where people give voluntarily of their spare time, people with assigned hats are not always available. They must therefore appoint a deputy that can perform the hat's role in their absence. The other option is to have the role held by a group. Muitos committers têm uma área especial de responsabilidade. Esses papéis são chamados de hats. Esses títulos podem ser funções do projeto, como diretor de relações públicas ou mantenedor de uma determinada área do código. Como esse é um projeto em que as pessoas doam voluntariamente seu tempo livre, as pessoas com hats atribuídos nem sempre estão disponíveis. Eles devem, portanto, nomear um substituto que possa desempenhar o cargo de hat em sua ausência. A outra opção é ter o cargo ocupado por um grupo.
Many of these hats are not formalised. Formalised hats have a charter stating the exact purpose of the hat along with its privileges and responsibilities. The writing of such charters is a new part of the project, and has thus yet to be completed for all hats. These hat descriptions are not such a formalisation, rather a summary of the role with links to the charter where available and contact addresses. Muitos desses hats não são formalizados. Hats formalizados têm uma carta indicando o propósito exato do hat, juntamente com seus privilégios e responsabilidades. A redação de tais cartas é uma nova parte do projeto e, portanto, ainda não foi concluída para todos os hats. Essas descrições de hats não são uma formalização, e sim um resumo da função com links para a carta quando disponíveis e endereços de contato.
General Hats Hats Universais
Contributor Colaborador
A Contributor contributes to the FreeBSD project either as a developer, as an author, by sending problem reports, or in other ways contributing to the progress of the project. A contributor has no special privileges in the FreeBSD project. <citation><xref linkend="freebsd-contributors"/></citation> Um Colaborador contribui para o projeto do FreeBSD como desenvolvedor, como autor, enviando relatórios de problemas ou contribuindo de outras formas para o progresso do projeto. Um colaborador não tem privilégios especiais no projeto do FreeBSD. <citation><xref linkend="freebsd-contributors"/></citation>

Loading…

User avatar None

New source string

FreeBSD Doc / books_dev-model — Portuguese (Brazil)

New source string a year ago
Browse all component changes

Glossary

English Portuguese (Brazil)
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: section/para
Source string location
book.translate.xml:841
String age
a year ago
Source string age
a year ago
Translation file
books/pt_BR/dev-model.po, string 136