软件版本的划分及含义alpha、Beta、RELEASE、Stable等

最新推荐文章于 2024-01-24 09:28:24 发布
最新推荐文章于 2024-01-24 09:28:24 发布
阅读量4.8k 收藏 4
点赞数 2
文章标签： 源代码管理
原文链接：https://blog.csdn.net/qq_42855293/article/details/122908639
版权

转载添加链接描述
alpha
α是希腊字母的第一个，表示最早的版本，内部测试版，一般不向外部发布，bug会比较多，功能也不全，一般只有测试人员使用。

Beta
β是希腊字母的第二个，公开测试版，比alpha版本晚些，主要会有“粉丝用户”测试使用，该版本仍然存在很多bug，但比alpha版本稳定一些。这个阶段版本还会不断增加新功能。分为Beta1、Beta2等，直到逐渐稳定下来进入RC版本。

RC
Release Candidate，发行候选版本，基本不再加入新的功能，主要修复bug。是最终发布成正式版的前一个版本，将bug修改完就可以发布成正式版了。

GA
General Availability，正式发布的版本，官方开始推荐广泛使用，国外有的用GA来表示release版本。

RELEASE
正式发布版，官方推荐使用的版本，有的用GA来表示。比如spring。

Stable
稳定版，开源软件有的会用stable来表示正式发布的版本。比如Nginx。

Final
最终版，也是正式发布版的一种表示方法。比如Hibernate。

番外篇
授权和功能划分：
Trial：试用版，通常都有时间限制，有些试用版软件还在功能上做了一定的限制。可注册或购买成为正式版
Unregistered：未注册版，通常没有时间限制，在功能上相对于正式版做了一定的限制。可注册或购买成为正式版。
Demo：演示版，仅仅集成了正式版中的几个功能，不能升级成正式版。
Lite：精简版。
Full　version：完整版，属于正式版。

其他版本
Enhance　：增强版或者加强版　属于正式版1
Free　：自由版
Release　：发行版　有时间限制
Upgrade　：升级版
Retail　　：零售版
Cardware　：属共享软件的一种，只要给作者回复一封电邮或明信片即可。（有的作者并由此提供注册码等），目前这种形式已不多见。
Plus　：属增强版，不过这种大部分是在程序界面及多媒体功能上增强。
Preview　：预览版
Corporation　&　Enterprise　：企业版
Standard　：标准版
Mini　：迷你版也叫精简版只有最基本的功能
Premium　：　贵价版
Professional(Pro)　：　专业版
Express　：　特别版
Deluxe　：　豪华版
Regged　：　已注册版

Build:内部标号
Delux:豪华版 (deluxe: 豪华的，华丽的)
DEMO演示版，一般会有功能限制
Full:完全版
Plus:加强版
Trial:试用版（一般有时间或者功能限制）

a498420237
关注
  • 2
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
httpd2.2.12.tar
04-25
httpd2.2.12.tar编码工具APACHE 2.x VERSIONING ===================== [$LastChangedDate: 2005-10-17 17:17:21 +0000 (Mon, 17 Oct 2005) $] INTRODUCTION ------------ The Apache HTTP Server project must balance two competing and disjoint objectives: maintain stable code for third party authors, distributors and most importantly users so that bug and security fixes can be quickly adopted without significant hardship due to user-visible changes; and continue the development process that requires ongoing redesign to correct earlier oversights and to add additional features. The Apache HTTP Server, through version 2.0, used the Module Magic Number (MMN) to reflect API changes. This had the shortcoming of often leaving users hunting to replace binary third party modules that were now incompatible. This also left module authors searching through the API change histories to determine the exact cause for the MMN change and whether their module was affected. With the simultaneous release of Apache 2.2-stable and Apache 2.3-development, the Apache HTTP Server project is moving towards a more predictable stable release cycle, while allowing forward progress to occur without concern for breaking the stable branch. This document explains the rationale between the two versions and their behavior. STABLE RELEASES, 2.{even}.{revision} ------------------------------------ All even numbered releases will be considered stable revisions. Stable revisions will retain forward compatiblity to the maximum possible extent. Features may be added during minor revisions, and features may be deprecated by making appropriate notations in the documentation, but no features may be removed. In essence, that implies that you can upgrade from one minor revision to the next with a minimum of trouble. In particular, this means: * The Module API will retain forward compatibility. It will not be necessary to update modules to work with new revisions of the stable tree. * The run-time configuration will be forward compatible. No configuration changes will be necessary to work with new revisions of the stable tree. * Compile-time configuration will be forward compatible. The configure command line options that work in one release of the stable tree will also work in the next release. As always, it will be necessary to test any new release to assure that it works correctly with a particular configuration and a particular set of modules, but every effort will be made to assure that upgrades are as smooth as possible. In addition, the following development restrictions will aid in keeping the stable tree as safe as possible: * No 'Experimental' modules; while it may be possible (based on API changes required to support a given module) to load a 2.3-development module into a 2.2-stable build of Apache, there are no guarantees. Experimental modules will be introduced to the 2.3-development versions and either added to 2.2-stable once they are proven and compatible, or deferred to the 2.4-stable release if they cannot be incorporated in the current stable release due to API change requirements. * The stable subversion tree should not remain unstable at any time. Atomic commits aught be used to introduce code from the development version to the stable tree. At any given time a security release may be in preparation, unbeknownst to other contributors. At any given time, testers may be checking out SVN trunk to confirm that a bug has been corrected. And as all code was well-tested in development prior to committing to the stable tree, there is really no reason for this tree to be broken for more than a few minutes during a lengthy commit. In order to avoid 'skipped' release numbers in the stable releases, the Release Manager will generally roll a release candidate (APACHE_#_#_#_RC#) tag. Release Candidate tarballs will be announced to the stable[email protected] for the stable tree. Then, the participants will vote on the quality of the proposed release tarball. The final APACHE_#_#_# tag will not exist until the APACHE_#_#_#_RC# candidate has passed the usual votes to release that version. Only then is the final tarball packaged, removing all -rc# designations from the version number, and tagging the tree with the release number. DEVELOPMENT RELEASES, 2.{odd}.{revision} ----------------------------------------- All odd numbered releases designate the 'next' possible stable release, therefore the current development version will always be one greater than the current stable release. Work proceeds on development releases, permitting the modification of the MMN at any time in order to correct deficiencies or shortcomings in the API. This means that modules from one development release to another may not be binary compatible, or may not successfully compile without modification to accomodate the API changes. The only 'supported' development release at any time will be the most recently released version. Developers will not be answering bug reports of older development releases once a new release is available. It becomes the resposibility of the reporter to use the latest development version to confirm that any issue still exists. Any new code, new API features or new ('experimental') modules may be promoted at any time to the next stable release, by a vote of the project contributors. This vote is based on the technical stability of the new code and the stability of the interface. Once moved to stable, that feature cannot change for the remainder of that stable release cycle, so the vote must reflect that the final decisions on the behavior and naming of that new feature were reached. Vetos continue to apply to this choice of introducing the new work to the stable version. At any given time, when the quality of changes to the development branch is considered release quality, that version may become a candidate for the next stable release. This includes some or all of the API changes, promoting experimental modules to stable or deprecating and eliminating older modules from the last stable release. All of these choices are considered by the project as a group in the interests of promoting the stable release, so that any given change may be 'deferred' for a future release by the group, rather than introduce unacceptable risks to adopting the next stable release. Third party module authors are strongly encouraged to test with the latest development version. This assures that the module will be ready for the next stable release, but more importantly, the author can react to shortcomings in the API early enough to warn the [email protected] community of the shortcomings so that they can be addressed before the stable release. The entire burden is on the module author to anticipate the needs of their module before the stable release is created. Once a new stable release cycle has begun, that API will be present for the lifetime of the stable release. Any desired changes in the stable versions must wait for inclusion into the next release cycle. When deciding to promote a development tree to being stable, a determination should be made whether the changes since the last stable version warrant a major version bump. That is, if 2.2 is the current stable version and 2.3 is 'ready' to become stable, the group needs to decide if the next stable version is 2.4 or 3.0. One suggested rule of thumb is that if it requires too much effort to port a module from 2.2 to 2.4, then the stable version should be labeled 3.0. In order to ease the burden of creating development releases, the process for packaging a development releases is less formal than for the stable release. This strategy reflects the fact that while in development, versions are cheap. Development releases may be classified as alpha, beta, or GA to reflect the group's perceived stability of the tree. Development releases may be made at any time by any committer. Please read the following link for a more detailed description of the development release strategy: http://httpd.apache.org/dev/release.html
libevent-1.1b_1.4.13-stable_2.0.3-alpha 源码（资料中转）
12-08
libevent-1.1b ~ 1.4.13-stable ~ 2.0.3-alpha libevent-2.0.3-alpha.tar.gz [GPG Sig] - ChangeLog - Release 2009-11-19 libevent-1.4.13-stable.tar.gz [GPG Sig] - ChangeLog - Release 2009-11-17 libevent-1.4.12-stable.tar.gz [GPG Sig] - ChangeLog - Release 2009-07-24 libevent-2.0.2-alpha.tar.gz [GPG Sig] - ChangeLog - Release 2009-07-24 libevent-1.4.11-stable.tar.gz [GPG Sig] - ChangeLog - Release 2009-05-14 libevent-2.0.1-alpha.tar.gz [GPG Sig] - What's new - Release 2009-04-17 libevent-1.4.10-stable.tar.gz [GPG Sig] - ChangeLog - Release 2009-04-17 libevent-1.4.9-stable.tar.gz [GPG Sig] - ChangeLog - Release 2008-12-12 libevent-1.4.8-stable.tar.gz [GPG Sig] - ChangeLog - Release 2008-09-13 libevent-1.4.7-stable.tar.gz [GPG Sig] - ChangeLog - Release 2008-08-25 libevent-1.4.6-stable.tar.gz [GPG Sig] - ChangeLog - Release 2008-07-24 libevent-1.4.5-stable.tar.gz [GPG Sig] - ChangeLog - Release 2008-06-25 libevent-1.4.4-stable.tar.gz [GPG Sig] - ChangeLog - Release 2008-05-13 libevent-1.4.3-stable.tar.gz [GPG Sig] - ChangeLog - Release 2008-04-07 libevent-1.4.2-rc.tar.gz [GPG Sig] - ChangeLog - Release 2008-02-25 make Solaris event subsystems more reliable; from W.C.A. Wijngaards event_base_get_method(); from Springande Ulv fix HTTP/1.1 chunk formatting; from "propanbutan" allow 64-bit content lengths; from Scott Lamb and more... libevent-1.4.1-beta.tar.gz [GPG Sig] - ChangeLog - Release 2007-12-21 fixed some memory leaks and other misc cleanup; from Christopher Layne, Scott Lamb and Charles Kerr introduced event_reinit to deal with fork() improved efficiency of generated RPC structure performance improvements to Win32 backend and many more... libevent-1.4.0-beta.tar.gz [GPG Sig] - ChangeLog - Release 2007-11-11 a new RPC subsytem for writing distributed clients and servers almost everything is documented via Doxygen now many fixes and improvements to evdns and evhttp libevent now builds two additional libraries: libevent_core (containing only
nextversion:格式化，修改和更新程序包版本
04-02
下一个版本 格式化，修改和更新Node.js和Python包操作的版本。 用法 先决条件 在存储库.github/workflows目录中创建一个工作流程.yml文件。 检查下面的。 有关更多信息，请参考GitHub帮助文档，用于。 输入项 姓名 默认 描述 path "" 包含当前版本的文件的路径，例如package.json ， pyproject.toml ， setup.cfg ， version.txt version "0.0.0" 当前版本要提高，如果可能，请使用path isadad type "semver" 版本类型： semver或pep440 release "stable" 发布类型： stable rc ， alpha或beta result "patch" 版本将其设置为result ： major ， minor ， patch
dubbo、dubbox编译所需jar包
09-01
ant-1.6.2.jar asm-analysis-3.2.jar asm-commons-3.2.jar asm-tree-3.2.jar asm-util-3.2.jar aspectjweaver-1.7.4.jar avalon-framework-4.1.3.jar bsf-api-3.1.jar cache-api-0.4.jar cglib-nodep-2.2.jar citrus-webx-all-3.0.8.jar classworlds-1.1-alpha-2.jar classworlds-1.1.jar commons-beanutils.jar commons-cli-1.0.jar commons-collections-3.2.jar commons-digester-1.6.jar commons-httpclient-2.0.2.jar commons-io-1.3.2.jar commons-io-2.1.jar commons-lang-2.5.jar commons-logging-1.1.jar commons-validator-1.2.0.jar curator-framework-1.1.16.jar cxf-rt-frontend-simple-2.6.1.jar cxf-rt-transports-http-2.6.1.jar doxia-core-1.0-alpha-11.jar doxia-core-1.0.jar doxia-decoration-model-1.0-alpha-11.jar doxia-decoration-model-1.0.jar doxia-module-apt-1.0-alpha-11.jar doxia-module-apt-1.0.jar doxia-module-fml-1.0-alpha-11.jar doxia-module-fml-1.0.jar doxia-module-xdoc-1.0-alpha-11.jar doxia-module-xdoc-1.0.jar doxia-module-xhtml-1.0-alpha-11.jar doxia-module-xhtml-1.0.jar doxia-sink-api-1.0-alpha-10.jar doxia-sink-api-1.0-alpha-11.jar doxia-sink-api-1.0-alpha-4.jar doxia-sink-api-1.0.jar doxia-site-renderer-1.0-alpha-11.jar doxia-site-renderer-1.0.jar dummy.jar.zip dummy1.0.jar easymock-1.2_Java1.3.jar easymock-3.0.jar easymockclassextension-3.0.jar fastjson-1.1.31.jar fastjson-1.2.28.jar fastjson-1.2.31.jar file-management-1.2.1.jar fst-1.55.jar grizzly-core-2.1.4.jar hessian-lite-3.2.1-fixed-2.jar hibernate-validator-4.2.0.Final.jar hsqldb-1.7.1.jar htmlunit-1.9.jar httpclient-4.0.1.jar httpclient-4.1.2.jar httpclient-4.2.5.jar httpclient-4.4.jar httpcore-4.0.1.jar httpcore-4.1.2.jar jackson-core-2.8.8.jar jackson-core-asl-1.9.13.jar jackson-databind-2.3.3.jar jackson-datatype-joda-2.4.0.jar jackson-mapper-asl-1.9.12.jar javassist-3.20.0-GA.jar javax.ws.rs-api-2.0.1.jar jaxen-core-1.0-FCS.jar jaxen-jdom-1.0-FCS.jar jdependency-0.6.jar jdom-1.1.jar jedis-2.1.0.jar jetty-4.2.10.jar jetty-4.2.12.jar jfreechart-1.0.13.jar jmockit-0.999.8.jar jsch-0.1.23.jar jsch-0.1.27.jar jsr305-2.0.1.jar jtid
10、嵌入式开发 | 软件项目中 Debug 和 Release 版本的差异
qq_43416206的博客
06-02 420
这里的“生成调试信息”其实包含了很多关于调试的信息，如果勾选会多出“.pbd”、 “.browse”、 “.linf”等与调试有关的信息。实际项目中，Debug 和 Release两个版本可能还有很多不同的配置，按理说“Options”下面的很多配置都可以不同。还是拿Keil 和 IAR 来说明，源码和工程结构都一样，只是配置不一样，简单来说，就是一个“克隆”版本。这里是说的“版本”是指Debug 和 Release中的版本，并不是软件版本或其他什么版本。
debug版本和release版本的区别
guangzizhaichen的博客
05-24 2082
14:release版本 就把arr[]内存地址 放在了i的下面 这样就不会出现越界访问i地址了 这就是release版本的自动优化的其中一点 无论arr[]在怎么越界 也不会碰触到i的内存地址了。12:debug版本在越界访问局部变量时就容易出现死循环 但是在release版本 就没有出现死循环 因为release版本对程序做了优化。13:arr[]数组的越界访问的前提是 arr[]数组的内存地址超过了i的内存地址。8:先定义的局部变量存储的内存地址 要高于 后定义的局部变量存储的内存地址。
软件中GA、Release、RC、Beta、Alpha 各版本号的意义
startyangu的博客
10-25 3718
软件中GA、Release、RC、Beta、Alpha 各版本号的意义
软件版本号讲解:什么是Alpha, Beta, RC，Release
kunwen123的博客
07-24 5177
文件名称由四部分组成：第一部分为项目名称，第二部分为文件的描述，第三部分为当前软件的版本号，第四部分为文件阶段标识加文件后缀，例如：项目外 包平台测试报告1.1.1.051021_beta_b.xls，此文件为项目外包平台的测试报告文档，版本号为：1.1.1.051021_beta。软件版本号由四部分组成，第一个1为主版本号，第二个1为子版本号，第三个1为阶段版本号，第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有5种，分别为：base、alpha、beta、RC、release。
Alpha、Beta、RC、Release版本的区别
qq_39510043的博客
10-16 1230
开发期 Alpha α是希腊字母的第一个，表示最早的版本，预览版，内部测试版，一般不向外部发布，bug会比较多，功能也不全，一般只有测试人员使用。 Beta β是希腊字母的第二个，公开测试版，比alpha版本晚些，主要会有“粉丝用户”测试使用，该版本仍然存在很多bug，但比alpha版本稳定一些。这个阶段版本还会不断增加新功能。分为Beta1、Beta2等，直到逐渐稳定下来进入RC版本。 R...
软件版本（release、stable、lastest）的区别
以秘
06-29 1万+
软件版本（release、stable、lastest）的区别
simple-tags
06-02
Stable tag: 2.2 Add some tools for taxonomies : Terms suggestion, Mass Edit Terms, Auto link Terms, Ajax Autocompletion, Click Terms, Auto terms, Advanced manage terms, Advanced Post Terms, Related ...
Alpha、Beta、Release、RC、GA等各版本称号的区别
qq_40151840的博客
02-25 559
经常在下载开源软件，比如Redis、Tomcat源代码的时候，被N多个版本迷花了眼，总是分不清版本后面所带的BETA、ALPHA、RC等版本号所表示的意义 ，现在整理学习下。 原文链接：https://blog.csdn.net/zhongqi2513/article/details/79990760 Alpha：是内部测试版,一般不向外部发布,会有很多Bug.一般只有测试人员使用。 Beta：也...
软件版本GA,RC,alpha,beta,Build 含义
热门推荐
Andes Home 千年的塔 -十年技术，风雨兼程
09-21 2万+
 软件版本GA,RC,alpha,beta,Build 含义（1）RC：(Release　Candidate)　　Candidate是候选人的意思，用在软件上就是候选版本。Release.Candidate.就是发行候选版本。和Beta版最大的差别在于Beta阶段会一直加入新的功能，但是到了RC版本，几乎就不会加入新的功能了，而主要着重于除错!        是最终发放
软件发布版本区别介绍-Alpha,Beta,RC,Release
weixin_34023982的博客
06-07 478
Alpha: Alpha是内部测试版,一般不向外部发布,会有很多Bug.除非你也是测试人员,否则不建议使用. 是希腊字母的第一位,表示最初级的版本 alpha就是α，beta就是β alpha版就是比beta还早的测试版，一般都是内部测试的版本 -------------------- Beta： 　　很容易理解就是测试版，这个阶段的版本会一直加入新的功能。 RC：RC就是...
【知识---各种软件开发状态的详细解释--Alpha、Beta 、Release Candidate (RC)、Stable、GA (General Availability)等】
最新发布
fyc300的博客
01-24 478
提示：以下是本篇文章正文内容，下面案例可供参考以上这些状态反映了软件在开发生命周期中的不同阶段，每个阶段都有其独特的特点和目标。在不同的组织和项目中，这些术语的具体定义和用法可能会有所不同。
什么是LTS、Alpha、Beta、Dev、Release、Patch版本，软件的开发周期有多少种命名
凌凌1301的博客
04-28 4375
说明：Pre-alpha是指在软件项目进行正式测试之前执行的所有活动。这些活动包括需求分析、软件设计、软件开发和单元测试。在典型的开源开发中，有几种类型的pre-alpha版本。里程碑版本包括特定的功能集，并在功能完成后尽快发布Alpha软件发布生命周期的alpha阶段是软件测试的第一阶段。在此阶段，开发人员通常使用白盒技术测试软件。然后，由另一个测试团队使用黑盒或灰盒技术进行额外的验证。向组织内部转换到黑盒测试称为alpha发布。
Maven中 SNAPSHOT版本和 Release版本区别
流楚丶格念的博客
08-31 2075
在软件开发中，版本控制是必不可少的。它有助于跟踪项目的变化、回滚错误和协调多个开发者的工作。Maven是Java世界中广泛使用的构建工具和依赖管理库，它对版本号的处理采用了一种独特的方式。在Maven中，版本号通常是一个三部分的版本号，例如1.0.0，也可以带有预发布标签，如1.0.0-SNAPSHOT。下面让我们深入探讨一下SNAPSHOT版本和RELEASE版本之间的区别。
Android studio的canary、dev、stable、beta版本区别
大喵爱吃鱼的博客
02-22 2万+
Android studio内置的更新机制分为canary、dev、stable、beta四个版本，根本上区分在于其稳定性。而as的更新机制默认是stable，因此此时即使有其他版本更新也无法检测到。具体设置如下：（1）Canary（中文名金丝雀）        也是as最早发布的预览不，用于获取开发过程中的真实反馈，通常一周更新一次，比如Android  Studio 3.2 Canary 2、...
软件版本的划分及含义(alpha、Beta等)
qq_42855293的博客
02-13 1万+
alpha α是希腊字母的第一个，表示最早的版本，内部测试版，一般不向外部发布，bug会比较多，功能也不全，一般只有测试人员使用。 Beta β是希腊字母的第二个，公开测试版，比alpha版本晚些，主要会有“粉丝用户”测试使用，该版本仍然存在很多bug，但比alpha版本稳定一些。这个阶段版本还会不断增加新功能。分为Beta1、Beta2等，直到逐渐稳定下来进入RC版本。 RC Release Candidate，发行候选版本，基本不再加入新的功能，主要修复bug。是最终发布成正式版的前一个版本，将bug修
alpha版本beta版本金丝雀版本和灰度版本
06-02
这四个版本都是软件开发中常见的版本类型，它们的含义如下： 1. Alpha版本：一般是在软件内部测试阶段，仅供内部人员使用。这个版本通常包含了基本功能，但可能存在严重的漏洞和问题。 2. Beta版本：一般是在Alpha版本测试后发布的测试版本，供有限的外部用户测试。这个版本通常包含了基本功能，但仍可能存在漏洞和问题。 3. 金丝雀版本：也称为Canary版本，是指一小部分用户在软件正式发布之前使用的版本。这个版本通常包含了所有功能，并且已经修复了大部分已知的漏洞和问题。通过这个版本，开发团队可以了解软件在实际使用中的表现。 4. 灰度版本：是指在软件发布后，将新版本仅部署给一部分用户进行测试和使用的版本。通过这个版本，开发团队可以了解软件在不同环境下的表现，并及时修复问题。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值