|
| 1 | +--- |
| 2 | +title: Ciclo de Vida do Software |
| 3 | +name: software-life-cycle |
| 4 | +id: pt_br-software-life-cycle |
| 5 | +permalink: /pt_br/lifecycle/ |
| 6 | +layout: page |
| 7 | +type: pages |
| 8 | +lang: pt_br |
| 9 | +version: 2 |
| 10 | +--- |
| 11 | +{% include toc.html %} |
| 12 | + |
| 13 | +Este documento descreve o ciclo de vida do pacote de software |
| 14 | +Bitcoin Core lançado pelo projeto Bitcoin Core. Ele está de acordo com |
| 15 | +a política padrão de manutenção dos softwares comerciais. |
| 16 | + |
| 17 | + |
| 18 | +## Versionamento |
| 19 | + |
| 20 | +Os lançamentos do Bitcoin Core são versionados seguindo: MAJOR.MINOR e |
| 21 | +lançamentos candidatos são atribuidos no sufixo rc1, rc2 e etc. |
| 22 | + |
| 23 | +## Lançamentos Major |
| 24 | + |
| 25 | +Nosso objetivo é fazer um grande lançamento a cada 6-7 meses. |
| 26 | + |
| 27 | +Essas serão numeradas 22.0, 23.0 etc. |
| 28 | + |
| 29 | +## Lançamentos de manutenção |
| 30 | + |
| 31 | +Nós forneceremos "lançamentos minor" para consertar bugs que |
| 32 | +vieram nos lançamentos major. Por regra geral, nós não introduzimos grandes |
| 33 | +mudanças em um lançamento de manutenção (exceto para regras de consenso). |
| 34 | +No entanto, nós podemos adicionar pequenas mudanças quando for necessário e |
| 35 | +faremos o back-port de alterações de regras de consenso, como soft forks. |
| 36 | + |
| 37 | +Lançamentos minor serão numerados 22.1, 22.2, 23.1, 23.2 etc. |
| 38 | + |
| 39 | +## Regra de consenso |
| 40 | + |
| 41 | +Propostas para mudar regras de consenso são sempre enviadas primeiro para a |
| 42 | +versão de manutenção como 22.2, 23.1 e etc. Isso torna mais fácil para usuários |
| 43 | +empresariais acessarem e testarem a proposta devido ao seu menor conjunto de |
| 44 | +alterações em comparação com um lançamento major. |
| 45 | + |
| 46 | +## Período de manutenção |
| 47 | + |
| 48 | +Nós mantemos a versão major até o seu "Fim de Manutenção". Nós geralmente |
| 49 | +mantemos os lançamentos das versões major corrente e a anterior. |
| 50 | +Uma vez lançada a versão 24.0, então a 22.0 será considerada como "Fim de |
| 51 | +Manutenção". Com o envelhecimento da versão major, problemas tem que ser cada |
| 52 | +vez mais críticos para serem reportados para ela e uma quantidade crescente de |
| 53 | +problemas severos é requerido para justificar uma nova versão minor. |
| 54 | +Uma vez que o software chegou ao período de "Fim de Manutenção", ela só |
| 55 | +receberá manutenção criticas de segurança até a data do Fim Ciclo de vida(FCV). |
| 56 | +Após o FCV, usuários devem atualizar para a última versão para receber |
| 57 | +atualizações de segurança, mesmo que a comunidade possa fornecer correções para |
| 58 | +problemas criticos baseado nos melhores esforços. |
| 59 | +Geralmente é recomendo executar a última versão lançada de manutenção (lançamento |
| 60 | +pontual) da versão atual ou anterior a major. |
| 61 | + |
| 62 | +Por favor, verifique se a versão minor tem correções, atualizações de tradução |
| 63 | +e soft forks. Tradução no [Transifex][bitcoin-transifex-link] só está |
| 64 | +disponível para os últimos dois lançamentos major. |
| 65 | + |
| 66 | +Por exemplo, a versão 22.0 foi lançada em 13-09-2021 e nós fornecemos |
| 67 | +manutenção de correção (lançamento atual) até 15-11-2022. |
| 68 | +Problemas criticos de segurança devem ser consertados até o Fim Ciclo de vida |
| 69 | +"FCV" na data de 01-04-2024. |
| 70 | +Portanto, para ter as vantagens dos bugs consertados, você deveria atualizar |
| 71 | +para a última versão major. |
| 72 | + |
| 73 | + |
| 74 | +## Agenda |
| 75 | + |
| 76 | +Uma vez que o FCV é atingido, você irá precisar atualizar para a versão mais |
| 77 | +nova. |
| 78 | + |
| 79 | +| Versão | Data de Lançamento | Fim manutenção | Fim Ciclo de vida | |
| 80 | +|--------|--------------------|----------------|------------------------| |
| 81 | +{% include posts/maintenance-table.md %} |
| 82 | + |
| 83 | +\* _Nosso objetivo é fazer um grande lançamento a cada 6-7 meses._ |
| 84 | + |
| 85 | +_TBA: a ser anunciado_ |
| 86 | + |
| 87 | +## Versões do protocolo |
| 88 | + |
| 89 | +A descrição abaixo somente descreve os lançamentos do software Bitcoin Core. |
| 90 | +Outras partes do projeto do sistema Bitcoin contém suas próprias versões. |
| 91 | +Alguns exemplos são: |
| 92 | +- Toda **transação** contem um número de versão. |
| 93 | +- O **protocolo da rede P2P** usa números de versões para permitir os nós |
| 94 | +informarem quais funcionalidades eles suportam. |
| 95 | +- **Carteira integrada** Bitcoin Core tem seu próprio número de versionamento |
| 96 | +interno. |
| 97 | + |
| 98 | +Estes números de versões são deliberadamente desvinculados do número de versão |
| 99 | +do projeto Bitcoin Core, uma vez que o projeto Bitcoin Core ou não tem controle |
| 100 | +direto sobre eles (como é o caso dos blocos e transações), ou tenta manter a |
| 101 | +compatibilidade com outros projetos (como é o caso com o protocolo de rede), ou |
| 102 | +permite a possibilidade que as modificações sejam feitas não em grandes |
| 103 | +lançamentos (como acontece, as vezes, na construção da carteira). |
| 104 | + |
| 105 | +O protocolo de consenso, por si só, não tem um número de versão. |
| 106 | + |
| 107 | +## Relacionamento com SemVer |
| 108 | + |
| 109 | +O versionamento do software Bitcoin Core não segue o padrão de versionamento |
| 110 | +opcional [SemVer][], más é lançado um versionamento superficialmente similar. |
| 111 | +SemVer foi designado para uso em bibliotecas de softwares normais |
| 112 | +onde indivíduos podem escolher atualizar a biblioteca no seu próprio local, ou |
| 113 | +podem permanecer em uma versão anterior caso não goste das modificações. |
| 114 | + |
| 115 | +Partes do Bitcoin, mais notadamente a regra de consenso, não funciona dessa |
| 116 | +maneira. A fim que uma nova regra de consenso entre em atividade, ela |
| 117 | +precisa ser aceita por um número de mineradores, full nodes ou ambos; e uma vez |
| 118 | +que ela tenha efeito, softwares que não conhecem aquelas novas regras podem |
| 119 | +gerar ou aceitar transações inválidas (embora as atualizações sejam desenhadas |
| 120 | +para prevenir que esse tipo de comportamento aconteça). |
| 121 | + |
| 122 | +Por essa razão, o Bitcoin Core desvia da regra de consenso do SemVer e outras |
| 123 | +atualizações onde a adoção em toda a rede é necessária ou desejável. Bitcoin |
| 124 | +Core lança essas mudanças como lançamentos de manutenção (`x.y`) ao invés de |
| 125 | +um lançamento major (`x.0`); isso minimiza o tamanho da modificação para tornar |
| 126 | +mais fácil possível para a maioria das pessoas inspecionar, testar e implanta- |
| 127 | +la. Isso também permite enviar a modificação para vários outros lançamentos |
| 128 | +majors, crescendo ainda mais o número de usuários que podem atualizar |
| 129 | +facilmente, embora não haja voluntários suficientes para gerenciar isso. |
| 130 | + |
| 131 | +[SemVer]: https://semver.org/ |
| 132 | +[bitcoin-transifex-link]: https://www.transifex.com/bitcoin/bitcoin/ |
0 commit comments