From ea9f44cfb6acd067f7188e9105d8417a2c919576 Mon Sep 17 00:00:00 2001 From: jlucfarias Date: Mon, 11 Sep 2023 18:36:50 -0300 Subject: [PATCH 1/7] Add v2.0.0-rc.2 PT-BR translation --- lang/pt-BR/spec/v2.0.0-rc.2.md | 261 +++++++++++++++++++++++++++++++++ 1 file changed, 261 insertions(+) create mode 100644 lang/pt-BR/spec/v2.0.0-rc.2.md diff --git a/lang/pt-BR/spec/v2.0.0-rc.2.md b/lang/pt-BR/spec/v2.0.0-rc.2.md new file mode 100644 index 00000000..eba91480 --- /dev/null +++ b/lang/pt-BR/spec/v2.0.0-rc.2.md @@ -0,0 +1,261 @@ +--- +title: Versionamento Semântico 2.0.0-rc.1 +language: pt-BR +--- + +Versionamento Semântico 2.0.0-rc.1 +================================== + +No mundo de gerenciamento de software existe algo terrível conhecido como +inferno das dependências ("dependency hell"). Quanto mais o sistema cresce, e +mais pacotes são adicionados a ele, maior será a possibilidade de, um dia, você +encontrar-se neste poço de desespero. + +Em sistemas com muitas dependências, lançar novos pacotes de versões pode se +tornar rapidamente um pesadelo. Se as especificações das dependências são muito +amarradas você corre o risco de um bloqueio de versão (A falta de capacidade de +atualizar um pacote sem ter de liberar novas versões de cada pacote dependente). +Se as dependências são vagamente especificadas, você irá inevitavelmente ser +mordido pela 'promiscuidade da versão' (assumindo compatibilidade com futuras +versões mais do que é razoável). O inferno das dependências é onde você está +quando um bloqueio de versão e/ou promiscuidade de versão te impede de seguir +em frente com seu projeto de maneira fácil e segura. + +Como uma solução para este problema proponho um conjunto simples de regras e +requisitos que ditam como os números das versões são atribuídos e incrementados. + +Para que este sistema funcione, primeiro você precisa declarar uma API pública. +Isto pode consistir de documentação ou ser determinada pelo próprio código. De +qualquer maneira, é importante que esta API seja clara e precisa. Depois de +identificada a API pública, você comunica as mudanças com incrementos +específicos para o seu número de versão. Considere o formato de versão X.Y.Z +(Maior.Menor.Correção). Correção de falhas (bug fixes) que não afetam a API, +incrementa a versão de Correção, adições/alterações compatíveis com as versões +anteriores da API incrementa a versão Menor, e alterações incompatíveis com as +versões anteriores da API incrementa a versão Maior. + +Eu chamo esse sistema de "Versionamento Semântico". Sob este esquema, os números +de versão e a forma como eles mudam, transmite o significado do código +subjacente e o que foi modificado de uma versão para a próxima. + +Especificação de Versionamento Semântico (SemVer) +------------------------------------------------- + +As palavras-chaves "DEVE", "NÃO DEVE", "OBRIGATÓRIO", "DEVERÁ", "NÃO DEVERÁ", +"DEVERIA", "NÃO DEVERIA", "RECOMENDADO", "PODE" e "OPCIONAL" no presente +documento devem ser interpretados como descrito na [RFC 2119] +(http://tools.ietf.org/html/rfc2119). + +1. Software usando Versionamento Semântico DEVE declarar uma API pública. Esta +API poderá ser declarada no próprio código ou existir estritamente na +documentação, desde que seja precisa e compreensiva. + +1. Um número de versão normal DEVE ter o formato de X.Y.Z, onde X, Y, e Z são +inteiros não negativos. X é a versão Maior, Y é a versão Menor, e Z é a versão +de Correção. Cada elemento DEVE aumentar numericamente por incrementos de um. +Por exemplo: 1.9.0 -> 1.10.0 -> 1.11.0. + +1. Uma vez que um pacote versionado foi lançado (released), o conteúdo desta +versão NÃO DEVE ser modificado. Qualquer modificação DEVE ser lançado como uma +nova versão. + +1. No início do desenvolvimento, a versão Maior DEVE ser zero (0.y.z). Qualquer +coisa pode mudar a qualquer momento. A API pública não deve ser considerada +estável. + +1. Versão 1.0.0 define a API como pública. A maneira como o número de versão é +incrementado após este lançamento é dependente da API pública e como ela muda. + +1. Versão de Correção Z (x.y.Z | x > 0) DEVE ser incrementado apenas se mantiver +compatibilidade e introduzir correção de bugs. Uma correção de bug é definida +como uma mudança interna que corrige um comportamento incorreto. + +1. Versão Menor Y (x.Y.z | x > 0) DEVE ser incrementada se uma funcionalidade +nova e compatível for introduzida na API pública. DEVE ser incrementada se +qualquer funcionalidade da API pública for definida como descontinuada. PODE ser +incrementada se uma nova funcionalidade ou melhoria substancial for introduzida +dentro do código privado. PODE incluir mudanças a nível de correção. A versão de +Correção deve ser redefinida para 0(zero) quando a versão Menor for +incrementada. + +1. Versão Maior X (X.y.z | X > 0) DEVE ser incrementada se forem introduzidas +mudanças incompatíveis na API pública. PODE incluir alterações a nível de versão +Menor e de versão de Correção. Versão de Correção e Versão Menor devem ser +redefinidas para 0(zero) quando a versão Maior for incrementada. + +1. Uma versão de Pré-Lançamento (pre-release) PODE ser identificada adicionando +um hífen e uma série de identificadores separados por ponto (dot) +imediatamente após a versão de Correção. o identificador DEVE compreender +apenas caracteres alfanumérios e hífen [0-9A-Za-z-]. Versão de +Pré-Lançamento tem precedência inferior à versão normal a que está associada. +Exemplos: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92. + +1. Metadados de Construção (build) PODE ser identificada por adicionar um +sinal de adição (+) e uma série de identificadores separados por ponto +imediatamente após a versão de Correção ou Pré-Lançamento. Identificador DEVE +compreende apenas caracteres alfanumérios e hífen [0-9A-Za-z-]. Metadados de +Construção DEVEM ser ignorados quando for determinada uma versão precendente. +Por isso, dois pacotes com a mesma versão, mas diferentes metadados de construção +são considerados sendo da mesma versão. Exemplos: +1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85. + +1. A precendência DEVE ser calculada separando identificadores de versão em +Maior, Menor, Correção e Pré-lançamento, nesta ordem (metadados de construção +não possuem precendência). Versões Maior, Menor e Correção são sempre +comparadas numericamente. A precedência de versões de Pré-lançamento DEVE ser +determinada comparando cada identificador separado por ponto da seguinte forma: identificadores consistindo apenas dígitos são comparados numericamente e +identificadores com letras ou hífen são comparados lexicalmente na ordem de +classificação ASCII. +Identificadores numéricos sempre têm menor precedência do que os não numéricos. +Exemplo: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 +< 1.0.0. + +Por que usar Versionamento Semântico? +------------------------------------- + +Esta não é uma ideia nova ou revolucionária. De fato, você provavelmente já faz +algo próximo a isso. O problema é que "próximo" não é bom o bastante. Sem a +aderência a algum tipo de especificação formal, os números de versão são +essencialmente inúteis para gerenciamento de dependências. Dando um nome e +definições claras às ideias acima, fica fácil comunicar suas intenções aos +usuários de seu software. Uma vez que estas intenções estão claras, +especificações de dependências flexíveis (mas não tão flexíveis) finalmente +podem ser feitas. + +Um exemplo simples vai demonstrar como o Versionamento Semântico pode fazer do +inferno de dependência uma coisa do passado. Considere uma biblioteca chamada +"CaminhaoBombeiros". Ela requer um pacote versionado dinamicamente chamado +"Escada". Quando CaminhaoBombeiros foi criado, Escada estava na versão 3.1.0. +Como CaminhaoBombeiros utiliza algumas funcionalidades que foram inicialmente +introduzidas na versão 3.1.0, você pode especificar, com segurança, a +dependência da Escada como maior ou igual a 3.1.0 porém menor que 4.0.0. Agora, +quando Escada versão 3.1.1 e 3.2.0 estiverem disponíveis, você poderá lançá-los +ao seu sistema de gerenciamento de pacote e saberá que eles serão compatíveis +com os softwares dependentes existentes. + +Como um desenvolvedor responsável você irá, é claro, querer certificar-se que +qualquer atualização no pacote funcionará como anunciado. O mundo real é um +lugar bagunçado; não há nada que possamos fazer quanto a isso senão sermos +vigilantes. O que você pode fazer é deixar o Versionamento Semântico lhe +fornecer uma maneira sensata de lançar e atualizar pacotes sem precisar +atualizar para novas versões de pacotes dependentes, salvando-lhe tempo e +aborrecimento. + +Se tudo isto soa desejável, tudo que você precisar fazer para começar a usar +Versionamento Semântico é declarar que você o esta usando e então, seguir as +regras. Adicione um link para este website no seu README para que outros saibam +as regras e possam beneficiar-se delas. + +FAQ +--- + +### Como devo lidar com revisões na fase 0.y.z de desenvolvimento inicial? + +A coisa mais simples a se fazer é começar sua versão de desenvolvimento inicial +em 0.1.0 e, então, incrementar a uma versão 'menor' em cada lançamento +subsequente. + +### Como eu sei quando lançar a versão 1.0.0? + +Se seu software está sendo usado em produção, ele já deve ser provavelmente +1.0.0. Se você possui uma API estável a qual usuários passaram a depender, deve +ser 1.0.0. Se você está se preocupando bastante com compatibilidade com versões +anteriores, já deve ser 1.0.0. + +### Isto não desencoraja o desenvolvimento ágil e iteração rápida? + +A versão Maior zero tem o foco exatamente no desenvolvimento rápido. Se você +está mudando a API todo dia, provavelmente você está na versão 0.y.z ou num +branch separado de desenvolvimento, trabalhando numa próxima versão Maior. + +### Se mesmo a menor mudança incompatível com a API pública requer aumento da versão maior, não vou acabar na versão 42.0.0 muito rapidamente? + +Esta é uma questão de desenvolvimento responsável e conhecimento antecipado. +Mudanças incompatíveis não devem ser levemente introduzidas para o software que +tem um monte de código dependente. O custo que deve ser incorrido para atualizar +pode ser significante. Tendo que aumentar a versão maior para lançar mudanças +incompatíveis, significa que você pensará no impacto das suas mudanças, e +avaliará a relação de custo/benefício envolvida. + +### Documentar toda a API pública dá muito trabalho! + +É sua responsabilidade como desenvolvedor profissional documentar corretamente o +software que será usado por outros. Gerenciar a complexidade de software é uma +parte muito importante para manter o projeto eficiente, e isto é difícil de +fazer se ninguém sabe como usá-lo ou que métodos são seguros de chamar. A longo +prazo, Versionamento Semântico e a insistência em uma API pública bem definida +podem deixar tudo e todos funcionamente suavemente. + +### O que eu faço se, acidentalmente, liberar uma mudança incompatível com versões anteriores como uma versão menor (minor version)? + +Assim que você perceber que quebrou a especificação de versionamento semântico, +conserte o problema e lance uma nova versão menor, que corrige o problema e +restaura a retrocompatibilidade. Mesmo sob esta circunstância, é inaceitável +modificar versões lançadas. Se for apropriado, documente a versão ofensiva e +informe seus usuários do problema de forma que eles fiquem cientes da versão em +questão. + +### O que devo fazer se eu atualizar minhas próprias dependências sem modificar a API pública? + +Isso seria considerado compatível, uma vez que não afeta a API pública. Software +que depende explicitamente das mesmas dependências que seu pacote, deve ter sua +própria especificação de dependência e o autor notificará quaisquer conflitos. +Para determinar se a mudança é a nível de correção ou modificação de nível menor +dependente se você atualizou suas dependências a fim de corrigir um bug ou +introduzir nova funcionalidade. Eu normalmente esperaria código adicional para +última instância, caso em que é obviamente um incremento no nível menor. + +### O que devo fazer se o erro que está sendo corrigido retorna o código para estar em conformidade com a API pública (ou seja, o código estava incorretamente fora de sincronia com a documentação da API pública)? + +Use o bom senso. Se você tem um público enorme que será drasticamente impactado +pela mudança de comportamento de volta para o que a API pública pretendida, +então pode ser melhor realizar um lançamento de uma versão maior, mesmo que a +correção pudesse ser considerada estritamente uma versão de correção.Lembre-se, +Versionamento Semântico trata de transmitir o conhecimento das mudanças +ocorridas na versão. Se estas mudanças são importantes para seus usuários, +utilize o número da versão para informá-los. + +### Como devo lidar com descontinuação de funcionalidades? + +Descontinuar funcionalidades é um processo comum no desenvolvimento de software +e muitas vezes é necessário para haver progresso. Quando você descontinua parte +de sua API pública, você deve fazer duas coisas: (1) atualizar sua documentação, +para que os usuários saibam das mudanças, (2) lançar uma versão Menor anunciando +a descontinuação. Antes de remover completamente a funcionalidade em uma versão +Maior deve haver ao menos uma versão Menor que possui a descontinução anunciada, +fazendo com que os usuários realizem uma transição tranquila para a nova API. + +Sobre +----- + +A Especificação da Semântica de Versionamento é autoria de [Tom +Preston-Werner](http://tom.preston-werner.com), criador do Gravatars e +co-fundador do GitHub. + +A tradução deste documento para Português-Brasil foi iniciada de forma +colaborativa pela [Wend Tecnologia](https://github.com/wendtecnologia) através +de [Walker de Alencar Oliveira](https://github.com/walkeralencar) e teve a +participação de: + +- [William G. Comnisky](https://github.com/wcomnisky) +- [Rafael Sirotheau](https://github.com/rafasirotheau) +- [Arthur Almeida](https://github.com/arthuralmeidap) +- [Alberto Guimarães Viana](https://github.com/albertogviana) +- [Rafael Lúcio](https://github.com/poste9) +- Josiel Rocha +- Alessandro Leite +- Vinícius Assef +- [Silas Ribas Martins](https://github.com/silasrm) +- [Rogerio Prado de Jesus](https://github.com/rogeriopradoj) +- [João Lucas Farias](https://github.com/jlucfarias) + +Toda colaboração na tradução pode ser acompanhada no link: +http://pad.okfn.org/p/Fh9hjBPVu9 + +Caso queira deixar sua opinião, por favor [abra uma issue no +GitHub](https://github.com/mojombo/semver/issues). + +Licença +------- + +[Creative Commons ― CC BY 3.0](http://creativecommons.org/licenses/by/3.0/) From bb250f318cda8fc9bbc7ceda25c5fb8b16a81596 Mon Sep 17 00:00:00 2001 From: jlucfarias Date: Mon, 11 Sep 2023 18:51:35 -0300 Subject: [PATCH 2/7] Removing v2.0.0-rc.2 changes from v2.0.0-rc.1 --- lang/pt-BR/spec/v2.0.0-rc.1.md | 42 +++++++++++++++++++--------------- 1 file changed, 24 insertions(+), 18 deletions(-) diff --git a/lang/pt-BR/spec/v2.0.0-rc.1.md b/lang/pt-BR/spec/v2.0.0-rc.1.md index 185447c9..63b73e60 100644 --- a/lang/pt-BR/spec/v2.0.0-rc.1.md +++ b/lang/pt-BR/spec/v2.0.0-rc.1.md @@ -43,34 +43,38 @@ Especificação de Versionamento Semântico (SemVer) As palavras-chaves "DEVE", "NÃO DEVE", "OBRIGATÓRIO", "DEVERÁ", "NÃO DEVERÁ", "DEVERIA", "NÃO DEVERIA", "RECOMENDADO", "PODE" e "OPCIONAL" no presente -documento devem ser interpretados como descrito na [RFC 2119] -(http://tools.ietf.org/html/rfc2119). +documento devem ser interpretados como descrito na RFC 2119. 1. Software usando Versionamento Semântico DEVE declarar uma API pública. Esta API poderá ser declarada no próprio código ou existir estritamente na documentação, desde que seja precisa e compreensiva. -2. Um número de versão normal DEVE ter o formato de X.Y.Z, onde X, Y, e Z são +1. Um número de versão normal DEVE ter o formato de X.Y.Z, onde X, Y, e Z são inteiros não negativos. X é a versão Maior, Y é a versão Menor, e Z é a versão de Correção. Cada elemento DEVE aumentar numericamente por incrementos de um. Por exemplo: 1.9.0 -> 1.10.0 -> 1.11.0. -3. Uma vez que um pacote versionado foi lançado (released), o conteúdo desta -versão NÃO DEVE ser modificado. Qualquer modificação DEVE ser lançado como uma +1. Quando o número de uma versão maior for incrementado, a versão menor e a +versão de correção DEVEM ser reinicializadas para 0 (zero). Quando o número de +uma versão menor foi incrementado, a versão de correção DEVE ser reinicializada +como 0 (zero). Por exemplo: 1.1.3 -> 2.0.0 e 2.1.7 -> 2.2.0. + +1. Uma vez que um pacote versionado foi lançado (released), o conteúdo desta +versão NÃO DEVE ser modificado. Qualquer modificação deve ser lançado como uma nova versão. -4. No início do desenvolvimento, a versão Maior DEVE ser zero (0.y.z). Qualquer +1. No início do desenvolvimento, a versão Maior DEVE ser zero (0.y.z). Qualquer coisa pode mudar a qualquer momento. A API pública não deve ser considerada estável. -5. Versão 1.0.0 define a API como pública. A maneira como o número de versão é +1. Versão 1.0.0 define a API como pública. A maneira como o número de versão é incrementado após este lançamento é dependente da API pública e como ela muda. -6. Versão de Correção Z (x.y.Z | x > 0) DEVE ser incrementado apenas se mantiver +1. Versão de Correção Z (x.y.Z | x > 0) DEVE ser incrementado apenas se mantiver compatibilidade e introduzir correção de bugs. Uma correção de bug é definida como uma mudança interna que corrige um comportamento incorreto. -7. Versão Menor Y (x.Y.z | x > 0) DEVE ser incrementada se uma funcionalidade +1. Versão Menor Y (x.Y.z | x > 0) DEVE ser incrementada se uma funcionalidade nova e compatível for introduzida na API pública. DEVE ser incrementada se qualquer funcionalidade da API pública for definida como descontinuada. PODE ser incrementada se uma nova funcionalidade ou melhoria substancial for introduzida @@ -78,26 +82,26 @@ dentro do código privado. PODE incluir mudanças a nível de correção. A vers Correção deve ser redefinida para 0(zero) quando a versão Menor for incrementada. -8. Versão Maior X (X.y.z | X > 0) DEVE ser incrementada se forem introduzidas +1. Versão Maior X (X.y.z | X > 0) DEVE ser incrementada se forem introduzidas mudanças incompatíveis na API pública. PODE incluir alterações a nível de versão Menor e de versão de Correção. Versão de Correção e Versão Menor devem ser redefinidas para 0(zero) quando a versão Maior for incrementada. -9. Uma versão de Pré-Lançamento (pre-release) PODE ser identificada adicionando +1. Uma versão de Pré-Lançamento (pre-release) PODE ser identificada adicionando um hífen (dash) e uma série de identificadores separados por ponto (dot) imediatamente após a versão de Correção. o identificador DEVE ser composto apenas por caracteres alfanumérios e hífen [0-9A-Za-z-]. Versão de Pré-Lançamento tem precedência inferior à versão normal a que está associada. Exemplos: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92. -10. Uma versão de Construção (build) PODE ser identificada por adicionar um +1. Uma versão de Construção (build) PODE ser identificada por adicionar um sinal de adição (+) e uma série de identificadores separados por ponto imediatamente após a versão de Correção ou Pré-Lançamento. Identificador DEVE ser composto apenas por caracteres alfanumérios e hífen [0-9A-Za-z-]. Versões de Construção têm precedência maior à versão normal a que está associada. Exemplos: 1.0.0+build.1, 1.3.7+build.11.e0f985a. -11. A precendência DEVE ser calculada separando identificadores de versão em +1. A precendência DEVE ser calculada separando identificadores de versão em Maior, Menor, Correção, Pré-lançamento e Construção, nesta ordem. Versões Maior, Menor e Correção são sempre comparadas numericamente. A precedência de versões de Pré-lançamento e Construção DEVE ser determinada comparando cada @@ -111,6 +115,7 @@ Exemplo: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 Por que usar Versionamento Semântico? ------------------------------------- + Esta não é uma ideia nova ou revolucionária. De fato, você provavelmente já faz algo próximo a isso. O problema é que "próximo" não é bom o bastante. Sem a aderência a algum tipo de especificação formal, os números de versão são @@ -163,7 +168,7 @@ anteriores, já deve ser 1.0.0. ### Isto não desencoraja o desenvolvimento ágil e iteração rápida? A versão Maior zero tem o foco exatamente no desenvolvimento rápido. Se você -está mudando a API todo dia, provavelmente você está na versão 0.y.z ou num +está mudando a API todo dia, provavelmente você está na versão 0.x.x ou num branch separado de desenvolvimento, trabalhando numa próxima versão Maior. ### Se mesmo a menor mudança incompatível com a API pública requer aumento da versão maior, não vou acabar na versão 42.0.0 muito rapidamente? @@ -188,10 +193,10 @@ podem deixar tudo e todos funcionamente suavemente. Assim que você perceber que quebrou a especificação de versionamento semântico, conserte o problema e lance uma nova versão menor, que corrige o problema e -restaura a compatibilidade. Mesmo sob esta circunstância, é inaceitável -modificar versões lançadas. Se for apropriado, documente a versão ofensiva e -informe seus usuários do problema de forma que eles fiquem cientes da versão em -questão. +restaura a compatibilidade. Lembre-se que é inaceitável modificar versões +lançadas, mesmo sob essas circustâncias. Se for apropriado, documente a versão +ofensiva e informe seus usuários do problema de forma que eles fiquem cientes da +versão em questão. ### O que devo fazer se eu atualizar minhas próprias dependências sem modificar a API pública? @@ -245,6 +250,7 @@ participação de: - Vinícius Assef - [Silas Ribas Martins](https://github.com/silasrm) - [Rogerio Prado de Jesus](https://github.com/rogeriopradoj) +- [João Lucas Farias](https://github.com/jlucfarias) Toda colaboração na tradução pode ser acompanhada no link: http://pad.okfn.org/p/Fh9hjBPVu9 From c14b24010897de7af2009a55b17d5dfc3e8804fa Mon Sep 17 00:00:00 2001 From: jlucfarias Date: Mon, 11 Sep 2023 18:52:18 -0300 Subject: [PATCH 3/7] Improving a bit the v2.0.0 translation --- lang/pt-BR/spec/v2.0.0.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lang/pt-BR/spec/v2.0.0.md b/lang/pt-BR/spec/v2.0.0.md index 54bab3a8..f52b5e02 100644 --- a/lang/pt-BR/spec/v2.0.0.md +++ b/lang/pt-BR/spec/v2.0.0.md @@ -229,7 +229,7 @@ questão. ### O que devo fazer se eu atualizar minhas próprias dependências sem modificar a API pública? Isso seria considerado compatível, uma vez que não afeta a API pública. Software -que depende explicitamente da mesmas dependências que seu pacote, deve ter sua +que depende explicitamente das mesmas dependências que seu pacote, deve ter sua própria especificação de dependência e o autor notificará quaisquer conflitos. Para determinar se a mudança é a nível de correção ou modificação de nível menor dependente se você atualizou suas dependências a fim de corrigir um bug ou @@ -284,6 +284,7 @@ participação de: - Vinícius Assef - [Silas Ribas Martins](https://github.com/silasrm) - [Rogerio Prado de Jesus](https://github.com/rogeriopradoj) +- [João Lucas Farias](https://github.com/jlucfarias) Toda colaboração na tradução pode ser acompanhada no link: http://pad.okfn.org/p/Fh9hjBPVu9 From 4f43df1150b6f73f07a287ee76f246cea1c7e482 Mon Sep 17 00:00:00 2001 From: jlucfarias Date: Mon, 11 Sep 2023 19:48:26 -0300 Subject: [PATCH 4/7] Add v1.0.0 PT-BR translation --- lang/pt-BR/spec/v1.0.0.md | 233 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 233 insertions(+) create mode 100644 lang/pt-BR/spec/v1.0.0.md diff --git a/lang/pt-BR/spec/v1.0.0.md b/lang/pt-BR/spec/v1.0.0.md new file mode 100644 index 00000000..0d74264d --- /dev/null +++ b/lang/pt-BR/spec/v1.0.0.md @@ -0,0 +1,233 @@ +--- +title: Versionamento Semântico 1.0.0 +language: pt-BR +--- + +Versionamento Semântico 1.0.0 +============================= + +No mundo de gerenciamento de software existe algo terrível conhecido como +inferno das dependências ("dependency hell"). Quanto mais o sistema cresce, e +mais pacotes são adicionados a ele, maior será a possibilidade de, um dia, você +encontrar-se neste poço de desespero. + +Em sistemas com muitas dependências, lançar novos pacotes de versões pode se +tornar rapidamente um pesadelo. Se as especificações das dependências são muito +amarradas você corre o risco de um bloqueio de versão (A falta de capacidade de +atualizar um pacote sem ter de liberar novas versões de cada pacote dependente). +Se as dependências são vagamente especificadas, você irá inevitavelmente ser +mordido pela 'promiscuidade da versão' (assumindo compatibilidade com futuras +versões mais do que é razoável). O inferno das dependências é onde você está +quando um bloqueio de versão e/ou promiscuidade de versão te impede de seguir +em frente com seu projeto de maneira fácil e segura. + +Como uma solução para este problema proponho um conjunto simples de regras e +requisitos que ditam como os números das versões são atribuídos e incrementados. + +Para que este sistema funcione, primeiro você precisa declarar uma API pública. +Isto pode consistir de documentação ou ser determinada pelo próprio código. De +qualquer maneira, é importante que esta API seja clara e precisa. Depois de +identificada a API pública, você comunica as mudanças com incrementos +específicos para o seu número de versão. Considere o formato de versão X.Y.Z +(Maior.Menor.Correção). Correção de falhas (bug fixes) que não afetam a API, +incrementa a versão de Correção, adições/alterações compatíveis com as versões +anteriores da API incrementa a versão Menor, e alterações incompatíveis com as +versões anteriores da API incrementa a versão Maior. + +Eu chamo esse sistema de "Versionamento Semântico". Sob este esquema, os números +de versão e a forma como eles mudam, transmite o significado do código +subjacente e o que foi modificado de uma versão para a próxima. + +Especificação de Versionamento Semântico (SemVer) +------------------------------------------------- + +As palavras-chaves "DEVE", "NÃO DEVE", "OBRIGATÓRIO", "DEVERÁ", "NÃO DEVERÁ", +"DEVERIA", "NÃO DEVERIA", "RECOMENDADO", "PODE" e "OPCIONAL" no presente +documento devem ser interpretados como descrito na RFC 2119. + +1. Software usando Versionamento Semântico DEVE declarar uma API pública. Esta +API poderá ser declarada no próprio código ou existir estritamente na +documentação, desde que seja precisa e compreensiva. + +1. Um número de versão normal DEVE ter o formato de X.Y.Z, onde X, Y, e Z são +inteiros. X é a versão Maior, Y é a versão Menor, e Z é a versão de Correção. +Cada elemento DEVE aumentar numericamente por incrementos de um. +Por exemplo: 1.9.0 -> 1.10.0 -> 1.11.0. + +1. Quando o número de uma versão maior for incrementado, a versão menor e a +versão de correção DEVEM ser reinicializadas para 0 (zero). Quando o número de +uma versão menor foi incrementado, a versão de correção DEVE ser reinicializada +como 0 (zero). Por exemplo: 1.1.3 -> 2.0.0 e 2.1.7 -> 2.2.0. + +1. Uma versão de Pré-Lançamento (pre-release) PODE ser identificada adicionando +um texto arbitrário imediatamente após a versão de correção e um ponto (decimal +point). Esse texto DEVE ser composto por apenas caracteres alfanuméricos e +hífen (dash) [0-9A-Za-z-] e DEVE começar com um caractere alfabético [A-Za-z]. +Versão de Pré-Lançamento tem precedência inferior à versão normal a que está +associada. A precedência DEVE ser determinada lexicalmente na ordem de +classificação ASCII. Por exemplo: 1.0.0.alpha1 < 1.0.0.beta1 < 1.0.0.beta2 +< 1.0.0.rc1 < 1.0.0. + +1. Uma vez que um pacote versionado foi lançado (released), o conteúdo desta +versão NÃO DEVE ser modificado. Qualquer modificação deve ser lançado como uma +nova versão. + +1. No início do desenvolvimento, a versão Maior DEVE ser zero (0.y.z). Qualquer +coisa pode mudar a qualquer momento. A API pública não deve ser considerada +estável. + +1. Versão 1.0.0 define a API como pública. A maneira como o número de versão é +incrementado após este lançamento é dependente da API pública e como ela muda. + +1. Versão de Correção Z (x.y.Z | x > 0) DEVE ser incrementado apenas se mantiver +compatibilidade e introduzir correção de bugs. Uma correção de bug é definida +como uma mudança interna que corrige um comportamento incorreto. + +1. Versão Menor Y (x.Y.z | x > 0) DEVE ser incrementada se uma funcionalidade +nova e compatível for introduzida na API pública. PODE ser incrementada se +uma nova funcionalidade ou melhoria substancial for introduzida +dentro do código privado. PODE incluir mudanças a nível de correção. + +1. Versão Maior X (X.y.z | X > 0) DEVE ser incrementada se forem introduzidas +mudanças incompatíveis na API pública. PODE incluir alterações a nível de versão +Menor e de versão de Correção. + +Especificação de Rotulação (SemVerTag) +--------------------------------- + +Esta sub-especificação DEVE ser utilizada se você utilizar um sistema de +controle de versão (Git, Mercurial, SVN, etc) para armazenar seus códigos. A +utilização de um sistema desses permite às ferramentas de automação a +inspecionar o seu pacote e determinar a conformidade com o Versionamento +Semântico e das versões lançadas. + +1. Quando for rotular lançamentos em sistemas de controle de versão, o rótulo +para uma versão DEVE ser "vX.Y.Z" e.g. "v3.1.0". + +1. A primeira revisão a introduzir conformidade com o Versionamento Semântico +DEVE ser rotulada com "semver". Isso permite que projetos pré-existentes a +assumirem a conformidade em algum ponto arbitrário e para ferramentas de +automação a descobrirem isso. + +Por que usar Versionamento Semântico? +------------------------------------- + +Esta não é uma ideia nova ou revolucionária. De fato, você provavelmente já faz +algo próximo a isso. O problema é que "próximo" não é bom o bastante. Sem a +aderência a algum tipo de especificação formal, os números de versão são +essencialmente inúteis para gerenciamento de dependências. Dando um nome e +definições claras às ideias acima, fica fácil comunicar suas intenções aos +usuários de seu software. Uma vez que estas intenções estão claras, +especificações de dependências flexíveis (mas não tão flexíveis) finalmente +podem ser feitas. + +Um exemplo simples vai demonstrar como o Versionamento Semântico pode fazer do +inferno de dependência uma coisa do passado. Considere uma biblioteca chamada +"CaminhaoBombeiros". Ela requer um pacote versionado dinamicamente chamado +"Escada". Quando CaminhaoBombeiros foi criado, Escada estava na versão 3.1.0. +Como CaminhaoBombeiros utiliza algumas funcionalidades que foram inicialmente +introduzidas na versão 3.1.0, você pode especificar, com segurança, a +dependência da Escada como maior ou igual a 3.1.0 porém menor que 4.0.0. Agora, +quando Escada versão 3.1.1 e 3.2.0 estiverem disponíveis, você poderá lançá-los +ao seu sistema de gerenciamento de pacote e saberá que eles serão compatíveis +com os softwares dependentes existentes. + +Como um desenvolvedor responsável você irá, é claro, querer certificar-se que +qualquer atualização no pacote funcionará como anunciado. O mundo real é um +lugar bagunçado; não há nada que possamos fazer quanto a isso senão sermos +vigilantes. O que você pode fazer é deixar o Versionamento Semântico lhe +fornecer uma maneira sensata de lançar e atualizar pacotes sem precisar +atualizar para novas versões de pacotes dependentes, salvando-lhe tempo e +aborrecimento. + +Se tudo isto soa desejável, tudo que você precisar fazer para começar a usar +Versionamento Semântico é declarar que você o esta usando e então, seguir as +regras. Adicione um link para este website no seu README para que outros saibam +as regras e possam beneficiar-se delas. + +FAQ +--- + +### Como eu sei quando lançar a versão 1.0.0? + +Se seu software está sendo usado em produção, ele já deve ser provavelmente +1.0.0. Se você possui uma API estável a qual usuários passaram a depender, deve +ser 1.0.0. Se você está se preocupando bastante com compatibilidade com versões +anteriores, já deve ser 1.0.0. + +### Isto não desencoraja o desenvolvimento ágil e iteração rápida? + +A versão Maior zero tem o foco exatamente no desenvolvimento rápido. Se você +está mudando a API todo dia, provavelmente você está na versão 0.x.x ou num +branch separado de desenvolvimento, trabalhando numa próxima versão Maior. + +### Se mesmo a menor mudança incompatível com a API pública requer aumento da versão maior, não vou acabar na versão 42.0.0 muito rapidamente? + +Esta é uma questão de desenvolvimento responsável e conhecimento antecipado. +Mudanças incompatíveis não devem ser levemente introduzidas para o software que +tem um monte de código dependente. O custo que deve ser incorrido para atualizar +pode ser significante. Tendo que aumentar a versão maior para lançar mudanças +incompatíveis, significa que você pensará no impacto das suas mudanças, e +avaliará a relação de custo/benefício envolvida. + +### Documentar toda a API pública dá muito trabalho! + +É sua responsabilidade como desenvolvedor profissional documentar corretamente o +software que será usado por outros. Gerenciar a complexidade de software é uma +parte muito importante para manter o projeto eficiente, e isto é difícil de +fazer se ninguém sabe como usá-lo ou que métodos são seguros de chamar. A longo +prazo, Versionamento Semântico e a insistência em uma API pública bem definida +podem deixar tudo e todos funcionamente suavemente. + +### O que eu faço se, acidentalmente, liberar uma mudança incompatível com versões anteriores como uma versão menor (minor version)? + +Assim que você perceber que quebrou a especificação de versionamento semântico, +conserte o problema e lance uma nova versão menor, que corrige o problema e +restaura a compatibilidade. Lembre-se que é inaceitável modificar versões +lançadas, mesmo sob essas circustâncias. Se for apropriado, documente a versão +ofensiva e informe seus usuários do problema de forma que eles fiquem cientes da +versão em questão. + +### O que devo fazer se eu atualizar minhas próprias dependências sem modificar a API pública? + +Isso seria considerado compatível, uma vez que não afeta a API pública. Software +que depende explicitamente da mesmas dependências que seu pacote, deve ter sua +própria especificação de dependência e o autor notificará quaisquer conflitos. +Para determinar se a mudança é a nível de correção ou modificação de nível menor +dependente se você atualizou suas dependências a fim de corrigir um bug ou +introduzir nova funcionalidade. Eu normalmente esperaria código adicional para +última instância, caso em que é obviamente um incremento no nível menor. + +Sobre +----- + +A Especificação da Semântica de Versionamento é autoria de [Tom +Preston-Werner](http://tom.preston-werner.com), criador do Gravatars e +co-fundador do GitHub. + +A tradução deste documento para Português-Brasil foi iniciada de forma +colaborativa pela [Wend Tecnologia](https://github.com/wendtecnologia) através +de [Walker de Alencar Oliveira](https://github.com/walkeralencar) e teve a +participação de: + +- [William G. Comnisky](https://github.com/wcomnisky) +- [Rafael Sirotheau](https://github.com/rafasirotheau) +- [Arthur Almeida](https://github.com/arthuralmeidap) +- [Alberto Guimarães Viana](https://github.com/albertogviana) +- [Rafael Lúcio](https://github.com/poste9) +- Josiel Rocha +- Alessandro Leite +- Vinícius Assef +- [Silas Ribas Martins](https://github.com/silasrm) +- [Rogerio Prado de Jesus](https://github.com/rogeriopradoj) +- [João Lucas Farias](https://github.com/jlucfarias) + +Toda colaboração na tradução pode ser acompanhada no link: +http://pad.okfn.org/p/Fh9hjBPVu9 + +Caso queira deixar sua opinião, por favor [abra uma issue no GitHub](https://github.com/mojombo/semver/issues). + +Licença +------- + +[Creative Commons ― CC BY 3.0](http://creativecommons.org/licenses/by/3.0/) From ac11565c315c2d1ea31db173f1bdeda910ba9784 Mon Sep 17 00:00:00 2001 From: jlucfarias Date: Mon, 11 Sep 2023 19:48:38 -0300 Subject: [PATCH 5/7] Add v1.0.0-beta PT-BR translation --- lang/pt-BR/spec/v1.0.0-beta.md | 205 +++++++++++++++++++++++++++++++++ 1 file changed, 205 insertions(+) create mode 100644 lang/pt-BR/spec/v1.0.0-beta.md diff --git a/lang/pt-BR/spec/v1.0.0-beta.md b/lang/pt-BR/spec/v1.0.0-beta.md new file mode 100644 index 00000000..d5040f9e --- /dev/null +++ b/lang/pt-BR/spec/v1.0.0-beta.md @@ -0,0 +1,205 @@ +--- +title: Versionamento Semântico 1.0.0-beta +language: pt-BR +--- + +Versionamento Semântico 1.0.0-beta +================================== + +No mundo de gerenciamento de software existe algo terrível conhecido como +inferno das dependências ("dependency hell"). Quanto mais o sistema cresce, e +mais pacotes são adicionados a ele, maior será a possibilidade de, um dia, você +encontrar-se neste poço de desespero. + +Em sistemas com muitas dependências, lançar novos pacotes de versões pode se +tornar rapidamente um pesadelo. Se as especificações das dependências são muito +amarradas você corre o risco de um bloqueio de versão (A falta de capacidade de +atualizar um pacote sem ter de liberar novas versões de cada pacote dependente). +Se as dependências são vagamente especificadas, você irá inevitavelmente ser +mordido pela 'promiscuidade da versão' (assumindo compatibilidade com futuras +versões mais do que é razoável). O inferno das dependências é onde você está +quando um bloqueio de versão e/ou promiscuidade de versão te impede de seguir +em frente com seu projeto de maneira fácil e segura. + +Como uma solução para este problema proponho um conjunto simples de regras e +requisitos que ditam como os números das versões são atribuídos e incrementados. + +Para que este sistema funcione, primeiro você precisa declarar uma API pública. +Isto pode consistir de documentação ou ser determinada pelo próprio código. De +qualquer maneira, é importante que esta API seja clara e precisa. Depois de +identificada a API pública, você comunica as mudanças com incrementos +específicos para o seu número de versão. Considere o formato de versão X.Y.Z +(Maior.Menor.Correção). Correção de falhas (bug fixes) que não afetam a API, +incrementa a versão de Correção, adições/alterações compatíveis com as versões +anteriores da API incrementa a versão Menor, e alterações incompatíveis com as +versões anteriores da API incrementa a versão Maior. + +Eu chamo esse sistema de "Versionamento Semântico". Sob este esquema, os números +de versão e a forma como eles mudam, transmite o significado do código +subjacente e o que foi modificado de uma versão para a próxima. + +Especificação de Versionamento Semântico (SemVer) +------------------------------------------------- + +As palavras-chaves "DEVE", "NÃO DEVE", "OBRIGATÓRIO", "DEVERÁ", "NÃO DEVERÁ", +"DEVERIA", "NÃO DEVERIA", "RECOMENDADO", "PODE" e "OPCIONAL" no presente +documento devem ser interpretados como descrito na RFC 2119. + +1. Software usando Versionamento Semântico DEVE declarar uma API pública. Esta +API poderá ser declarada no próprio código ou existir estritamente na +documentação, desde que seja precisa e compreensiva. + +1. Um número de versão normal DEVE ter o formato de X.Y.Z, onde X, Y, e Z são +inteiros. X é a versão Maior, Y é a versão Menor, e Z é a versão de Correção. +Cada elemento DEVE aumentar numericamente por incrementos de um. +Por exemplo: 1.9.0 -> 1.10.0 -> 1.11.0. + +1. Quando o número de uma versão maior for incrementado, a versão menor e a +versão de correção DEVEM ser reinicializadas para 0 (zero). Quando o número de +uma versão menor foi incrementado, a versão de correção DEVE ser reinicializada +como 0 (zero). Por exemplo: 1.1.3 -> 2.0.0 e 2.1.7 -> 2.2.0. + +1. A pre-release version number MAY be denoted by appending an arbitrary +string immediately following the patch version and a decimal point. The string +MUST be comprised of only alphanumerics plus dash [0-9A-Za-z-] and MUST begin +with an alpha character [A-Za-z]. Pre-release versions satisfy but have a +lower precedence than the associated normal version. Precedence SHOULD be +determined by lexicographic ASCII sort order. For instance: 1.0.0.alpha1 < +1.0.0.beta1 < 1.0.0.beta2 < 1.0.0.rc1 < 1.0.0. + +1. Once a versioned package has been released, the contents of that version +MUST NOT be modified. Any modifications must be released as a new version. + +1. Major version zero (0.y.z) is for initial development. Anything may change +at any time. The public API should not be considered stable. + +1. Version 1.0.0 defines the public API. The way in which the version number +is incremented after this release is dependent on this public API and how it +changes. + +1. Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards +compatible bug fixes are introduced. A bug fix is defined as an internal +change that fixes incorrect behavior. + +1. Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards +compatible functionality is introduced to the public API. It MAY be +incremented if substantial new functionality or improvements are introduced +within the private code. It MAY include patch level changes. + +1. Major version X (X.y.z | X > 0) MUST be incremented if any backwards +incompatible changes are introduced to the public API. It MAY include minor +and patch level changes. + +Tagging Specification (SemVerTag) +--------------------------------- + +This sub-specification SHOULD be used if you use a version control system +(Git, Mercurial, SVN, etc) to store your code. Using this system allows +automated tools to inspect your package and determine SemVer compliance and +released versions. + +1. When tagging releases in a version control system, the tag for a version +MUST be "vX.Y.Z" e.g. "v3.1.0". + +1. The first revision that introduces SemVer compliance SHOULD be tagged +"semver". This allows pre-existing projects to assume compliance at any +arbitrary point and for automated tools to discover this fact. + +Why Use Semantic Versioning? +---------------------------- + +This is not a new or revolutionary idea. In fact, you probably do something +close to this already. The problem is that "close" isn't good enough. Without +compliance to some sort of formal specification, version numbers are +essentially useless for dependency management. By giving a name and clear +definition to the above ideas, it becomes easy to communicate your intentions +to the users of your software. Once these intentions are clear, flexible (but +not too flexible) dependency specifications can finally be made. + +A simple example will demonstrate how Semantic Versioning can make dependency +hell a thing of the past. Consider a library called "Firetruck." It requires a +Semantically Versioned package named "Ladder." At the time that Firetruck is +created, Ladder is at version 3.1.0. Since Firetruck uses some functionality +that was first introduced in 3.1.0, you can safely specify the Ladder +dependency as greater than or equal to 3.1.0 but less than 4.0.0. Now, when +Ladder version 3.1.1 and 3.2.0 become available, you can release them to your +package management system and know that they will be compatible with existing +dependent software. + +As a responsible developer you will, of course, want to verify that any +package upgrades function as advertised. The real world is a messy place; +there's nothing we can do about that but be vigilant. What you can do is let +Semantic Versioning provide you with a sane way to release and upgrade +packages without having to roll new versions of dependent packages, saving you +time and hassle. + +If all of this sounds desirable, all you need to do to start using Semantic +Versioning is to declare that you are doing so and then follow the rules. Link +to this website from your README so others know the rules and can benefit from +them. + +FAQ +--- + +### How do I know when to release 1.0.0? + +If your software is being used in production, it should probably already be +1.0.0. If you have a stable API on which users have come to depend, you should +be 1.0.0. If you're worrying a lot about backwards compatibility, you should +probably already be 1.0.0. + +### Doesn't this discourage rapid development and fast iteration? + +Major version zero is all about rapid development. If you're changing the API +every day you should either still be in version 0.x.x or on a separate +development branch working on the next major version. + +### If even the tiniest backwards incompatible changes to the public API require a major version bump, won't I end up at version 42.0.0 very rapidly? + +This is a question of responsible development and foresight. Incompatible +changes should not be introduced lightly to software that has a lot of +dependent code. The cost that must be incurred to upgrade can be significant. +Having to bump major versions to release incompatible changes means you'll +think through the impact of your changes, and evaluate the cost/benefit ratio +involved. + +### Documenting the entire public API is too much work! + +It is your responsibility as a professional developer to properly document +software that is intended for use by others. Managing software complexity is a +hugely important part of keeping a project efficient, and that's hard to do if +nobody knows how to use your software, or what methods are safe to call. In +the long run, Semantic Versioning, and the insistence on a well defined public +API can keep everyone and everything running smoothly. + +### What do I do if I accidentally release a backwards incompatible change as a minor version? + +As soon as you realize that you've broken the Semantic Versioning spec, fix +the problem and release a new minor version that corrects the problem and +restores backwards compatibility. Remember, it is unacceptable to modify +versioned releases, even under this circumstance. If it's appropriate, +document the offending version and inform your users of the problem so that +they are aware of the offending version. + +### What should I do if I update my own dependencies without changing the public API? + +That would be considered compatible since it does not affect the public API. +Software that explicitly depends on the same dependencies as your package +should have their own dependency specifications and the author will notice any +conflicts. Determining whether the change is a patch level or minor level +modification depends on whether you updated your dependencies in order to fix +a bug or introduce new functionality. I would usually expect additional code +for the latter instance, in which case it's obviously a minor level increment. + +About +----- + +The Semantic Versioning specification is authored by [Tom Preston-Werner](http://tom.preston-werner.com), inventor of Gravatars and cofounder of GitHub. + +If you'd like to leave feedback, please [open an issue on GitHub](https://github.com/mojombo/semver.org/issues). + +License +------- + +Creative Commons ― CC BY 3.0 +http://creativecommons.org/licenses/by/3.0/ From 7dc0c460c50a48512e375966ef851249fdac2370 Mon Sep 17 00:00:00 2001 From: jlucfarias Date: Sat, 2 Dec 2023 17:28:14 -0300 Subject: [PATCH 6/7] Add left translation for v1.0.0-beta PT-BR --- lang/pt-BR/spec/v1.0.0-beta.md | 235 +++++++++++++++++---------------- 1 file changed, 122 insertions(+), 113 deletions(-) diff --git a/lang/pt-BR/spec/v1.0.0-beta.md b/lang/pt-BR/spec/v1.0.0-beta.md index d5040f9e..9113b45b 100644 --- a/lang/pt-BR/spec/v1.0.0-beta.md +++ b/lang/pt-BR/spec/v1.0.0-beta.md @@ -59,146 +59,155 @@ versão de correção DEVEM ser reinicializadas para 0 (zero). Quando o número uma versão menor foi incrementado, a versão de correção DEVE ser reinicializada como 0 (zero). Por exemplo: 1.1.3 -> 2.0.0 e 2.1.7 -> 2.2.0. -1. A pre-release version number MAY be denoted by appending an arbitrary -string immediately following the patch version and a decimal point. The string -MUST be comprised of only alphanumerics plus dash [0-9A-Za-z-] and MUST begin -with an alpha character [A-Za-z]. Pre-release versions satisfy but have a -lower precedence than the associated normal version. Precedence SHOULD be -determined by lexicographic ASCII sort order. For instance: 1.0.0.alpha1 < -1.0.0.beta1 < 1.0.0.beta2 < 1.0.0.rc1 < 1.0.0. - -1. Once a versioned package has been released, the contents of that version -MUST NOT be modified. Any modifications must be released as a new version. - -1. Major version zero (0.y.z) is for initial development. Anything may change -at any time. The public API should not be considered stable. - -1. Version 1.0.0 defines the public API. The way in which the version number -is incremented after this release is dependent on this public API and how it -changes. - -1. Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards -compatible bug fixes are introduced. A bug fix is defined as an internal -change that fixes incorrect behavior. - -1. Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards -compatible functionality is introduced to the public API. It MAY be -incremented if substantial new functionality or improvements are introduced -within the private code. It MAY include patch level changes. - -1. Major version X (X.y.z | X > 0) MUST be incremented if any backwards -incompatible changes are introduced to the public API. It MAY include minor -and patch level changes. - -Tagging Specification (SemVerTag) +1. Uma versão de Pré-Lançamento (pre-release) PODE ser identificada adicionando +um texto arbitrário imediatamente após a versão de correção e um ponto (decimal +point). Esse texto DEVE ser composto por apenas caracteres alfanuméricos e +hífen (dash) [0-9A-Za-z-] e DEVE começar com um caractere alfabético [A-Za-z]. +versões de Pré-Lançamento satisfazem, mas tem inferior à versão normal a que está +associada. A precedência DEVE ser determinada lexicalmente na ordem de +classificação ASCII. Por exemplo: 1.0.0.alpha1 < 1.0.0.beta1 < 1.0.0.beta2 +< 1.0.0.rc1 < 1.0.0. + +1. Uma vez que um pacote versionado foi lançado (released), o conteúdo desta +versão NÃO DEVE ser modificado. Qualquer modificação deve ser lançado como uma +nova versão. + +1. versão Maior DEVE ser zero (0.y.z) é para o início do desenvolvimento. +Qualquer coisa pode mudar a qualquer momento. A API pública não deve ser considerada +estável. + +1. Versão 1.0.0 define a API como pública. A maneira como o número de versão é +incrementado após este lançamento é dependente da API pública e como ela muda. + +1. Versão de Correção Z (x.y.Z | x > 0) DEVE ser incrementado apenas se mantiver +compatibilidade e introduzir correção de bugs. Uma correção de bug é definida +como uma mudança interna que corrige um comportamento incorreto. + +1. Versão Menor Y (x.Y.z | x > 0) DEVE ser incrementada se uma funcionalidade +nova e compatível for introduzida na API pública. PODE ser incrementada se +uma nova funcionalidade ou melhoria substancial for introduzida +dentro do código privado. PODE incluir mudanças a nível de correção. + +1. Versão Maior X (X.y.z | X > 0) DEVE ser incrementada se forem introduzidas +mudanças incompatíveis na API pública. PODE incluir alterações a nível de versão +Menor e de versão de Correção. + +Especificação de Rotulação (SemVerTag) --------------------------------- -This sub-specification SHOULD be used if you use a version control system -(Git, Mercurial, SVN, etc) to store your code. Using this system allows -automated tools to inspect your package and determine SemVer compliance and -released versions. +Esta sub-especificação DEVE ser utilizada se você utilizar um sistema de +controle de versão (Git, Mercurial, SVN, etc) para armazenar seus códigos. A +utilização de um sistema desses permite às ferramentas de automação a +inspecionar o seu pacote e determinar a conformidade com o Versionamento +Semântico e das versões lançadas. -1. When tagging releases in a version control system, the tag for a version -MUST be "vX.Y.Z" e.g. "v3.1.0". +1. Quando for rotular lançamentos em sistemas de controle de versão, o rótulo +para uma versão DEVE ser "vX.Y.Z" e.g. "v3.1.0". -1. The first revision that introduces SemVer compliance SHOULD be tagged -"semver". This allows pre-existing projects to assume compliance at any -arbitrary point and for automated tools to discover this fact. +1. A primeira revisão a introduzir conformidade com o Versionamento Semântico +DEVE ser rotulada com "semver". Isso permite que projetos pré-existentes a +assumirem a conformidade em algum ponto arbitrário e para ferramentas de +automação a descobrirem isso. -Why Use Semantic Versioning? +Por que usar Versionamento Semântico? ---------------------------- -This is not a new or revolutionary idea. In fact, you probably do something -close to this already. The problem is that "close" isn't good enough. Without -compliance to some sort of formal specification, version numbers are -essentially useless for dependency management. By giving a name and clear -definition to the above ideas, it becomes easy to communicate your intentions -to the users of your software. Once these intentions are clear, flexible (but -not too flexible) dependency specifications can finally be made. - -A simple example will demonstrate how Semantic Versioning can make dependency -hell a thing of the past. Consider a library called "Firetruck." It requires a -Semantically Versioned package named "Ladder." At the time that Firetruck is -created, Ladder is at version 3.1.0. Since Firetruck uses some functionality -that was first introduced in 3.1.0, you can safely specify the Ladder -dependency as greater than or equal to 3.1.0 but less than 4.0.0. Now, when -Ladder version 3.1.1 and 3.2.0 become available, you can release them to your -package management system and know that they will be compatible with existing -dependent software. - -As a responsible developer you will, of course, want to verify that any -package upgrades function as advertised. The real world is a messy place; -there's nothing we can do about that but be vigilant. What you can do is let -Semantic Versioning provide you with a sane way to release and upgrade -packages without having to roll new versions of dependent packages, saving you -time and hassle. - -If all of this sounds desirable, all you need to do to start using Semantic -Versioning is to declare that you are doing so and then follow the rules. Link -to this website from your README so others know the rules and can benefit from -them. +Esta não é uma ideia nova ou revolucionária. De fato, você provavelmente já faz +algo próximo a isso. O problema é que "próximo" não é bom o bastante. Sem a +aderência a algum tipo de especificação formal, os números de versão são +essencialmente inúteis para gerenciamento de dependências. Dando um nome e +definições claras às ideias acima, fica fácil comunicar suas intenções aos +usuários de seu software. Uma vez que estas intenções estão claras, +especificações de dependências flexíveis (mas não tão flexíveis) finalmente +podem ser feitas. + +Um exemplo simples vai demonstrar como o Versionamento Semântico pode fazer do +inferno de dependência uma coisa do passado. Considere uma biblioteca chamada +"CaminhaoBombeiros." Ela requer um pacote versionado semânticamente chamado +"Escada." Quando CaminhaoBombeiros foi criado, Escada estava na versão 3.1.0. +Como CaminhaoBombeiros utiliza algumas funcionalidades que foram inicialmente +introduzidas na versão 3.1.0, você pode especificar, com segurança, a +dependência da Escada como maior ou igual a 3.1.0 porém menor que 4.0.0. Agora, +quando Escada versão 3.1.1 e 3.2.0 estiverem disponíveis, você poderá lançá-los +ao seu sistema de gerenciamento de pacote e saberá que eles serão compatíveis +com os softwares dependentes existentes. + +Como um desenvolvedor responsável você irá, é claro, querer certificar-se que +qualquer atualização no pacote funcionará como anunciado. O mundo real é um +lugar bagunçado; não há nada que possamos fazer quanto a isso senão sermos +vigilantes. O que você pode fazer é deixar o Versionamento Semântico lhe +fornecer uma maneira sensata de lançar e atualizar pacotes sem precisar +atualizar para novas versões de pacotes dependentes, salvando-lhe tempo e +aborrecimento. + +Se tudo isto soa desejável, tudo que você precisar fazer para começar a usar +Versionamento Semântico é declarar que você o esta usando e então, seguir as +regras. Adicione um link para este website no seu README para que outros saibam +as regras e possam beneficiar-se delas. FAQ --- -### How do I know when to release 1.0.0? +### Como eu sei quando lançar a versão 1.0.0? -If your software is being used in production, it should probably already be -1.0.0. If you have a stable API on which users have come to depend, you should -be 1.0.0. If you're worrying a lot about backwards compatibility, you should -probably already be 1.0.0. +Se seu software está sendo usado em produção, ele já deve ser provavelmente +1.0.0. Se você possui uma API estável a qual usuários passaram a depender, deve +ser 1.0.0. Se você está se preocupando bastante com compatibilidade com versões +anteriores, já deve ser 1.0.0. -### Doesn't this discourage rapid development and fast iteration? +### Isto não desencoraja o desenvolvimento ágil e iteração rápida? -Major version zero is all about rapid development. If you're changing the API -every day you should either still be in version 0.x.x or on a separate -development branch working on the next major version. +A versão Maior zero tem o foco exatamente no desenvolvimento rápido. Se você +está mudando a API todo dia, provavelmente você está na versão 0.x.x ou num +branch separado de desenvolvimento, trabalhando numa próxima versão Maior. -### If even the tiniest backwards incompatible changes to the public API require a major version bump, won't I end up at version 42.0.0 very rapidly? +### Se mesmo a menor mudança incompatível com a API pública requer aumento da versão maior, não vou acabar na versão 42.0.0 muito rapidamente? -This is a question of responsible development and foresight. Incompatible -changes should not be introduced lightly to software that has a lot of -dependent code. The cost that must be incurred to upgrade can be significant. -Having to bump major versions to release incompatible changes means you'll -think through the impact of your changes, and evaluate the cost/benefit ratio -involved. +Esta é uma questão de desenvolvimento responsável e conhecimento antecipado. +Mudanças incompatíveis não devem ser levemente introduzidas para o software que +tem um monte de código dependente. O custo que deve ser incorrido para atualizar +pode ser significante. Tendo que aumentar a versão maior para lançar mudanças +incompatíveis, significa que você pensará no impacto das suas mudanças, e +avaliará a relação de custo/benefício envolvida. -### Documenting the entire public API is too much work! +### Documentar toda a API pública dá muito trabalho! -It is your responsibility as a professional developer to properly document -software that is intended for use by others. Managing software complexity is a -hugely important part of keeping a project efficient, and that's hard to do if -nobody knows how to use your software, or what methods are safe to call. In -the long run, Semantic Versioning, and the insistence on a well defined public -API can keep everyone and everything running smoothly. +É sua responsabilidade como desenvolvedor profissional documentar corretamente o +software que será usado por outros. Gerenciar a complexidade de software é uma +parte muito importante para manter o projeto eficiente, e isto é difícil de +fazer se ninguém sabe como usá-lo ou que métodos são seguros de chamar. A longo +prazo, Versionamento Semântico e a insistência em uma API pública bem definida +podem deixar tudo e todos funcionando suavemente. -### What do I do if I accidentally release a backwards incompatible change as a minor version? +### O que eu faço se, acidentalmente, liberar uma mudança incompatível com versões anteriores como uma versão menor (minor version)? -As soon as you realize that you've broken the Semantic Versioning spec, fix -the problem and release a new minor version that corrects the problem and -restores backwards compatibility. Remember, it is unacceptable to modify -versioned releases, even under this circumstance. If it's appropriate, -document the offending version and inform your users of the problem so that -they are aware of the offending version. +Assim que você perceber que quebrou a especificação de versionamento semântico, +conserte o problema e lance uma nova versão menor, que corrige o problema e +restaura a compatibilidade. Lembre-se que é inaceitável modificar versões +lançadas, mesmo sob essas circustâncias. Se for apropriado, documente a versão +ofensiva e informe seus usuários do problema de forma que eles fiquem cientes da +versão em questão. -### What should I do if I update my own dependencies without changing the public API? +### O que devo fazer se eu atualizar minhas próprias dependências sem modificar a API pública? -That would be considered compatible since it does not affect the public API. -Software that explicitly depends on the same dependencies as your package -should have their own dependency specifications and the author will notice any -conflicts. Determining whether the change is a patch level or minor level -modification depends on whether you updated your dependencies in order to fix -a bug or introduce new functionality. I would usually expect additional code -for the latter instance, in which case it's obviously a minor level increment. +Isso seria considerado compatível, uma vez que não afeta a API pública. Software +que depende explicitamente da mesmas dependências que seu pacote, deve ter sua +própria especificação de dependência e o autor notificará quaisquer conflitos. +Para determinar se a mudança é a nível de correção ou modificação de nível menor +dependente se você atualizou suas dependências a fim de corrigir um bug ou +introduzir nova funcionalidade. Eu normalmente esperaria código adicional para +última instância, caso em que é obviamente um incremento no nível menor. -About +Sobre ----- -The Semantic Versioning specification is authored by [Tom Preston-Werner](http://tom.preston-werner.com), inventor of Gravatars and cofounder of GitHub. +A Especificação da Semântica de Versionamento é autoria de [Tom +Preston-Werner](http://tom.preston-werner.com), criador do Gravatars e +co-fundador do GitHub. -If you'd like to leave feedback, please [open an issue on GitHub](https://github.com/mojombo/semver.org/issues). +Caso queira deixar sua opinião, por favor [abra uma issue no GitHub](https://github.com/mojombo/semver/issues). -License +Licença ------- Creative Commons ― CC BY 3.0 From 040c232387a01763b9da3d3d3dcae45658d63016 Mon Sep 17 00:00:00 2001 From: jlucfarias Date: Sat, 2 Dec 2023 17:36:23 -0300 Subject: [PATCH 7/7] Removing translator's names section from spec files --- lang/pt-BR/spec/v1.0.0.md | 20 -------------------- lang/pt-BR/spec/v2.0.0-rc.1.md | 20 -------------------- lang/pt-BR/spec/v2.0.0-rc.2.md | 20 -------------------- lang/pt-BR/spec/v2.0.0.md | 20 -------------------- 4 files changed, 80 deletions(-) diff --git a/lang/pt-BR/spec/v1.0.0.md b/lang/pt-BR/spec/v1.0.0.md index 0d74264d..69969b21 100644 --- a/lang/pt-BR/spec/v1.0.0.md +++ b/lang/pt-BR/spec/v1.0.0.md @@ -205,26 +205,6 @@ A Especificação da Semântica de Versionamento é autoria de [Tom Preston-Werner](http://tom.preston-werner.com), criador do Gravatars e co-fundador do GitHub. -A tradução deste documento para Português-Brasil foi iniciada de forma -colaborativa pela [Wend Tecnologia](https://github.com/wendtecnologia) através -de [Walker de Alencar Oliveira](https://github.com/walkeralencar) e teve a -participação de: - -- [William G. Comnisky](https://github.com/wcomnisky) -- [Rafael Sirotheau](https://github.com/rafasirotheau) -- [Arthur Almeida](https://github.com/arthuralmeidap) -- [Alberto Guimarães Viana](https://github.com/albertogviana) -- [Rafael Lúcio](https://github.com/poste9) -- Josiel Rocha -- Alessandro Leite -- Vinícius Assef -- [Silas Ribas Martins](https://github.com/silasrm) -- [Rogerio Prado de Jesus](https://github.com/rogeriopradoj) -- [João Lucas Farias](https://github.com/jlucfarias) - -Toda colaboração na tradução pode ser acompanhada no link: -http://pad.okfn.org/p/Fh9hjBPVu9 - Caso queira deixar sua opinião, por favor [abra uma issue no GitHub](https://github.com/mojombo/semver/issues). Licença diff --git a/lang/pt-BR/spec/v2.0.0-rc.1.md b/lang/pt-BR/spec/v2.0.0-rc.1.md index 63b73e60..f09c6b97 100644 --- a/lang/pt-BR/spec/v2.0.0-rc.1.md +++ b/lang/pt-BR/spec/v2.0.0-rc.1.md @@ -235,26 +235,6 @@ A Especificação da Semântica de Versionamento é autoria de [Tom Preston-Werner](http://tom.preston-werner.com), criador do Gravatars e co-fundador do GitHub. -A tradução deste documento para Português-Brasil foi iniciada de forma -colaborativa pela [Wend Tecnologia](https://github.com/wendtecnologia) através -de [Walker de Alencar Oliveira](https://github.com/walkeralencar) e teve a -participação de: - -- [William G. Comnisky](https://github.com/wcomnisky) -- [Rafael Sirotheau](https://github.com/rafasirotheau) -- [Arthur Almeida](https://github.com/arthuralmeidap) -- [Alberto Guimarães Viana](https://github.com/albertogviana) -- [Rafael Lúcio](https://github.com/poste9) -- Josiel Rocha -- Alessandro Leite -- Vinícius Assef -- [Silas Ribas Martins](https://github.com/silasrm) -- [Rogerio Prado de Jesus](https://github.com/rogeriopradoj) -- [João Lucas Farias](https://github.com/jlucfarias) - -Toda colaboração na tradução pode ser acompanhada no link: -http://pad.okfn.org/p/Fh9hjBPVu9 - Caso queira deixar sua opinião, por favor [abra uma issue no GitHub](https://github.com/mojombo/semver/issues). Licença diff --git a/lang/pt-BR/spec/v2.0.0-rc.2.md b/lang/pt-BR/spec/v2.0.0-rc.2.md index eba91480..662bb8e3 100644 --- a/lang/pt-BR/spec/v2.0.0-rc.2.md +++ b/lang/pt-BR/spec/v2.0.0-rc.2.md @@ -232,26 +232,6 @@ A Especificação da Semântica de Versionamento é autoria de [Tom Preston-Werner](http://tom.preston-werner.com), criador do Gravatars e co-fundador do GitHub. -A tradução deste documento para Português-Brasil foi iniciada de forma -colaborativa pela [Wend Tecnologia](https://github.com/wendtecnologia) através -de [Walker de Alencar Oliveira](https://github.com/walkeralencar) e teve a -participação de: - -- [William G. Comnisky](https://github.com/wcomnisky) -- [Rafael Sirotheau](https://github.com/rafasirotheau) -- [Arthur Almeida](https://github.com/arthuralmeidap) -- [Alberto Guimarães Viana](https://github.com/albertogviana) -- [Rafael Lúcio](https://github.com/poste9) -- Josiel Rocha -- Alessandro Leite -- Vinícius Assef -- [Silas Ribas Martins](https://github.com/silasrm) -- [Rogerio Prado de Jesus](https://github.com/rogeriopradoj) -- [João Lucas Farias](https://github.com/jlucfarias) - -Toda colaboração na tradução pode ser acompanhada no link: -http://pad.okfn.org/p/Fh9hjBPVu9 - Caso queira deixar sua opinião, por favor [abra uma issue no GitHub](https://github.com/mojombo/semver/issues). diff --git a/lang/pt-BR/spec/v2.0.0.md b/lang/pt-BR/spec/v2.0.0.md index f52b5e02..0829582d 100644 --- a/lang/pt-BR/spec/v2.0.0.md +++ b/lang/pt-BR/spec/v2.0.0.md @@ -269,26 +269,6 @@ A Especificação da Semântica de Versionamento é autoria de [Tom Preston-Werner](http://tom.preston-werner.com), criador do Gravatars e co-fundador do GitHub. -A tradução deste documento para Português-Brasil foi iniciada de forma -colaborativa pela [Wend Tecnologia](https://github.com/wendtecnologia) através -de [Walker de Alencar Oliveira](https://github.com/walkeralencar) e teve a -participação de: - -- [William G. Comnisky](https://github.com/wcomnisky) -- [Rafael Sirotheau](https://github.com/rafasirotheau) -- [Arthur Almeida](https://github.com/arthuralmeidap) -- [Alberto Guimarães Viana](https://github.com/albertogviana) -- [Rafael Lúcio](https://github.com/poste9) -- Josiel Rocha -- Alessandro Leite -- Vinícius Assef -- [Silas Ribas Martins](https://github.com/silasrm) -- [Rogerio Prado de Jesus](https://github.com/rogeriopradoj) -- [João Lucas Farias](https://github.com/jlucfarias) - -Toda colaboração na tradução pode ser acompanhada no link: -http://pad.okfn.org/p/Fh9hjBPVu9 - Caso queira deixar sua opinião, por favor [abra uma issue no GitHub](https://github.com/semver/semver/issues). Licença