如何理解开发中版本的意思x.y.z

Version 的定义是日常开发中必不可少的意见事情之一了,但往往很多人会很容易忽略他其中的一些意义,导致很多时候,分支混乱,版本混乱,后期维护成本高的情况,这种情况取决于怎么去定义咱们的版本,怎么去使用咱们的分支。在拥有良好的定义,清晰的结构与说明的情况下,是可以减少大部分让人头疼的细节问题,版本是其中的一个。

在业界,其实细心地朋友不难发现,有很多的很详细的解析,可能我写这一篇博客也是多次一举,完全可以引用网上的案例与解析。

首先说说github上面的一些开源软件的版本。

Alpha:
是内部测试版,一般不向外部发布,会有很多Bug.一般只有测试人员使用。

Beta:
也是测试版,这个阶段的版本会一直加入新的功能。在Alpha版之后推出。

RC:(Release Candidate)
顾名思义么 ! 用在软件上就是候选版本。系统平台上就是发行候选版本。RC版不会再加入新的功能了,主要着重于除错。

最后就是正式(release)版本了,一般这个版本不需要特别注明,只需要注明最终版本号即可。

那么在咱们日常的开发当中,x.y.z 分别代表什么呢?

一般情况下,我们是这么做的:

x=大版本,不向下兼容
y=特性版本,向下兼容
z=bug修复版本,向下兼容

个人理解,关键点在于咱们发布新版本的时候,是否需要考虑向下兼容,改动、新增是否影响已有业务,兼容?不兼容? 需要取决于产品的改动是否对已有结构,架构产生变化,而导致的兼容性问题,

距个例子: 某产品发布了第一个版本 v1.0.0,那么在下次新增功能的时候,不影响结构,是需要打什么版本呢? 应该是v1.1.0 而不是 v2.0.0,也不是 v1.0.1 ,因为发布的是一个新功能,而又不影响结构。 假如发布 v1.1.0 之后需要修复问题,那么版本就应该是 v1.1.1 而不是 v1.2.0

结合上述的版本说明,内测,公测举一反三,v1.2.0-rc1 第一个公测版本。

这些版本的定义也需要与 git 仓库 tag 进行结合,而不是全程都是 master,feature-xxx 这样子的分支进行操作。

特别注意的是,已经合并的分支,需要进行清除,不能永久保留无用分支在项目上。

如果对于 git 不熟悉的朋友们,就需要好好补习一下git相关的操作了。

假如大伙还有不明白,可以假如交流群进行更多深入的交流:

QQ: 470565928
github: https://github.com/fastdlabs