Add v1.0.0-beta PT-BR translation

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/