基线 语义版本控制_语义版本控制：为什么要使用它

基线 语义版本控制

Semantic Versioning (referred to, for short, as SemVer), is a versioning system that has been on the rise over the last few years. With new plugins, addons, extensions, and libraries being built every day, having a universal way of versioning software development projects is a good thing to help us keep track of what’s going on.

语义版本控制(简称为SemVer )是一种在过去几年中呈上升趋势的版本控制系统。 随着每天都在构建新的插件，插件，扩展和库，拥有一种通用的软件开发项目版本控制方式是一件好事，可以帮助我们跟踪正在发生的事情。

什么是SemVer？ (What is SemVer?)

SemVer is a 3-component system in the format of x.y.z where:

SemVer是xyz格式的3组件系统，其中：

• x stands for a major version

  x代表主要版本

• y stands for a minor version

  y代表次要版本

• z stands for a patch

  z代表补丁

So you have: Major.Minor.Patch.

因此，您拥有： Major.Minor.Patch 。

SemVer如何工作？ (How Does SemVer work?)

SemVer relies on bumping the correct component up at the right time. Therefore, determining which type of version you should be releasing is simple.

SemVer依靠在正确的时间提升正确的组件。 因此，确定应该发布的版本类型很简单。

If you are mostly fixing bugs, then this would be categorized as a patch, in which case you should bump z.

如果您主要是在修复错误 ，则将其归类为补丁，在这种情况下，您应该碰到z 。

If you are implementing new features in a backward-compatible way, then you will bump y because this is what’s called a minor version.

如果您以向后兼容的方式实现新功能，那么您会碰到y因为这就是所谓的次要版本。

On the other hand, if you implement new stuff that is likely to break the existing API, you need to bump x because it is a major version.

另一方面，如果您实现的新东西很可能会破坏现有的API ，则您需要增加x因为它是主要版本。

为什么选择SemVer？ (Why SemVer?)

Because it makes sense. If there is one thing I’ve learned, it’s that versioning without guidelines basically means nothing. Moving to 4.2? Okay, fine. Why? Why not 5? Why not 4.1.1? Why not 4.11? Why not 4.1.oh-snap-new-version?

因为这很有意义。 如果我学到了一件事，那就是没有指导的版本控制基本上没有任何意义。 移至4.2？ 好的。 为什么？ 为什么不5？ 为什么不选择4.1.1？ 为什么不选择4.11？ 为什么不4.1.oh-snap-new-version？

Following strict guidelines helps give meaning to version numbers.

遵循严格的准则有助于使版本号有意义。

For example, if you see version 1.3.37, then you’ll know this is the first major release, but there have already been 3 minor versions bringing new features. However, you’ll also note that this is the 37th patch in this minor version, which means there were a lot of bugs (little or big) involved.

例如，如果您看到版本1.3.37，那么您将知道这是第一个主要版本，但是已经有3个次要版本带来了新功能。 但是，您还会注意到，这是此次要版本中的第37个补丁，这意味着其中涉及许多错误(小或大)。

Also it helps a lot in managing dependencies. Let’s say you are building a library called Unicorn. For whatever reasons, you have Rainbow as a dependency. When you get your lib out of the box for the first time, Rainbow is versioned 6.6.6 (looks nifty, huh?).

另外，它在管理依赖项方面也有很大帮助。 假设您正在建立一个名为Unicorn的图书馆。 无论出于何种原因，您都将Rainbow作为依赖项。 初次使用lib时， Rainbow的版本为6.6.6(看起来很漂亮，是吗？)。

That means you can specify Rainbow as a Unicorn dependency as greater than or equal to 6.6.0, but less than 7.0.0. Remember how the first number is the major patch with backward-apocalyptic changes? If someday Rainbow moves up to 7.0.0, nothing tells you that it won’t break Unicorn, so it’s best to keep it at version 6.

这意味着您可以将Rainbow指定为大于或等于6.6.0但小于7.0.0的Unicorn依赖项。 还记得第一个数字是向后变化的主要补丁吗？ 如果有一天Rainbow升至7.0.0，则不会告诉您它不会破坏Unicorn ，因此最好将其保持在版本6中。

注意事项 (Things to Keep in Mind)

Now that you know what SemVer is, let’s look at some of the things that might trip people up when first starting to use it.

现在您知道了SemVer是什么，让我们看一些可能在初次使用它时会绊倒人们的事情。

从0.1.0开始 (It Starts at 0.1.0)

One thing to note when using SemVer is that it starts at 0.1.0 and not at 0.0.1 like one would assume. If you think this through, it makes sense. You do not start with a patch, you start with a set of features as a first draft for your project, hence version 0.1.0.

使用SemVer时要注意的一件事是，它始于0.1.0，而不像人们想象的那样始于0.0.1。 如果您考虑透彻，那是有道理的。 您不是从补丁开始，而是从一组功能开始作为项目的初稿，因此版本为0.1.0。

1.0.0之前只是开发阶段 (Before 1.0.0 is Only the Development Phase)

Whenever you are building a new piece of software, there is always a phase where you keep asking yourself: When should I release the first official major version?

每当您构建新软件时，总会有一个阶段不断问自己：我什么时候应该发布第一个正式主版本？

Here are a few hints to help you answer to this question: If your software is already being used in production or has users depending on it, then you should already be at 1.0.0. Also, if you are worrying a lot about breaking the current API, this likewise probably means you should be running 1.0.0 already.

这里有一些提示可以帮助您回答这个问题：如果您的软件已经在生产中使用或有用户依赖它，那么您应该已经是1.0.0。 另外，如果您担心要破坏当前的API，同样可能意味着您应该已经在运行1.0.0。

Otherwise, keep in mind that versions below 1.0.0 are basically the development rush, where you focus on getting stuff done. Prior to 1.0.0, you shouldn’t be afraid of breaking things, and you’ll do whatever needs to be done so that when 1.0.0 is reached, it’s stable.

否则，请记住，低于1.0.0的版本基本上是开发高峰，您将专注于完成工作。 在1.0.0之前，您不必担心会发生问题，并且您将做任何需要做的事情，以便在达到1.0.0时保持稳定。

关于预发行 (About Pre-releases)

Before deploying a major version, you usually go through a lot of work that need to be tested again and again to make sure everything’s okay. That’s typically the moment you’d like to have a pre-release.

在部署主要版本之前，通常需要进行大量工作，这些工作需要一次又一次地进行测试，以确保一切正常。 通常是在您想要预发布的那一刻。

With SemVer, pre-releases can be defined by appending a hyphen and an identifier to a version. For example, a pre-release for version 1.0.0 could be 1.0.0-alpha.1. Then if another build is needed, it would become 1.0.0-alpha.2, and so on.

使用SemVer，可以通过在版本后附加连字符和标识符来定义预发行版本。 例如，版本1.0.0的预发行版可以是1.0.0-alpha.1。 然后，如果需要另一个构建，它将变成1.0.0-alpha.2，依此类推。

最后的想法 (Final Thoughts)

If you are not using SemVer, there is no legitimate excuse not to use it on your next project (or current project?). Not only does it help to keep things clean and meaningful, but it will also help other people who might be using your project as a dependency.

如果您不使用SemVer，则没有合法的借口不在下一个项目(或当前项目？)上使用它。 它不仅有助于保持事物的清洁和有意义，而且还可以帮助其他可能将您的项目用作依赖项的人。

翻译自: https://www.sitepoint.com/semantic-versioning-why-you-should-using/

基线 语义版本控制