【C++】OpenSSL发布策略/版本说明

https://www.openssl.org/policies/releasestrat.html

(英文原版见后半部分)

发布战略(谷歌翻译)

首次发布于2014年12月23日
最后修改于2019年2月25日

从3.0.0版开始,OpenSSL版本控制方案正在转变为更现代的格式:MAJOR.MINOR.PATCH

使用此格式,将保证相同MAJOR版本号的API / ABI兼容性。以前,我们保证在相同的MAJOR.MINOR组合中兼容API / ABI。

  • MAJOR:API / ABI不兼容的更改将增加此数量
  • MINOR:API / ABI兼容功能版本将改变这一点
  • PATCH:错误修复版本将增加此数字。我们还允许在这些版本中向后移植访问器功能。

这更符合熟悉语义版本控制的用户的期望。但是,我们没有严格意义上采用语义版本控制,因为它意味着改变我们当前的LTS策略和实践。

当前的1.1.1和1.0.2版本控制方案保持不变:

从版本1.0.0开始,OpenSSL版本控制方案得到了改进,以更好地满足开发人员和供应商的期望。信件发布,例如1.0.2a,仅包含错误和安全修复程序,没有新功能。更改最后一个数字的版本,例如1.1.0与1.1.1,可能并且可能包含新功能,但其方式不会破坏二进制兼容性。这意味着当共享库更新到1.1.1时,不需要重新编译与1.1.0编译和动态链接的应用程序。应该注意的是,某些功能对应用程序是透明的,例如最大协商的TLS版本和密码套件,性能改进等。

 


关于当前和未来的版本,OpenSSL项目采用了以下政策:

  • OpenSSL的下一个版本将是3.0.0。
  • 版本1.1.1将一直支持到2023-09-11(LTS)。
  • 版本1.1.0将一直支持到2019-09-11。
  • 版本1.0.2将一直支持到2019-12-31(LTS)。
  • 不再支持1.0.1版。
  • 不再支持1.0.0版。
  • 不再支持0.9.8版。

我们可以将版本指定为长期支持(LTS)版本。LTS版本将至少支持五年,我们将至少每四年指定一次。非LTS版本将至少支持两年。

在支持的最后一年,我们不承诺除安全修复之外的任何其他内容。在此之前,将适当地应用错误和安全修复程序。


在主要版本发布之前,我们会制作一些标记为alphabeta的预发行 

阿尔法释放装置:

  • 不是(必然)功能完整
  • 不一定所有的新API都已到位

一个测试版本是指:

  • 功能完整/功能冻结
  • 错误修复

对于任何主要或次要版本,我们已定义以下版本标准:

  • 所有在发布时超过2周的开放github问题/ PR需要评估与发布版本的相关性。任何标记有要发布的版本的里程碑的标记都必须关闭(见下文)。
  • 在Travis和Appveyor中清洁构建两天。
  • run-checker.sh在发布前连续2天成功。
  • 没有公开的Coverity问题(未标记为“误报”或“忽略”)。

使用该版本的里程碑关闭问题/ PR的有效原因可能是:

  • 我们刚才或过去的某个时候已经解决了这个问题
  • 无法复制(如果可能,请与原记者讨论)
  • 按预期工作
  • 故意决定在更新版本发布之前不解决此问题(这实际上不会关闭问题/ PR,而是更改里程碑)
  • 信息不足,无法联系记者

在次要版本或修补程序版本中不允许API或ABI中断更改。以下稳定性规则适用于针对3.0.0或更高版本的主要版本的目标代码所做的所有更改:

  • 除非更改不太可能破坏源兼容性或结构变得不透明,否则不能修改现有的公共接口。
  • 在LTS稳定版本中替换之前,不能删除现有的公共接口。原始界面也必须已被记录为已弃用至少5年。公共接口是在公共头文件中声明的任何函数,结构或宏。
  • 当结构变得不透明时,在现有LTS版本的功能版本和所有支持的中间版后续版本中添加任何新需要的访问者宏或函数。

英文原版:

First issued 23rd December 2014
Last modified 25th February 2019

As of release 3.0.0, the OpenSSL versioning scheme is changing to a more contemporary format: MAJOR.MINOR.PATCH

With this format, API/ABI compatibility will be guaranteed for the same MAJOR version number. Previously we guaranteed API/ABI compatibility across the same MAJOR.MINOR combination.

  • MAJOR: API/ABI incompatible changes will increase this number
  • MINOR: API/ABI compatible feature releases will change this
  • PATCH: Bug fix releases will increment this number. We also allow backporting of accessor functions in these releases.

This more closely aligns with the expectations of users who are familiar with semantic versioning. However, we have not adopted semantic versioning in the strict sense of its rules, because it would mean changing our current LTS policies and practices.

The current 1.1.1 and 1.0.2 versioning scheme remains unchanged:

As of release 1.0.0 the OpenSSL versioning scheme was improved to better meet developers' and vendors' expectations. Letter releases, such as 1.0.2a, exclusively contain bug and security fixes and no new features. Releases that change the last digit, e.g. 1.1.0 vs. 1.1.1, can and are likely to contain new features, but in a way that does not break binary compatibility. This means that an application compiled and dynamically linked with 1.1.0 does not need to be recompiled when the shared library is updated to 1.1.1. It should be noted that some features are transparent to the application such as the maximum negotiated TLS version and cipher suites, performance improvements and so on. There is no need to recompile applications to benefit from these features.

With regards to current and future releases the OpenSSL project has adopted the following policy:

  • The next version of OpenSSL will be 3.0.0.
  • Version 1.1.1 will be supported until 2023-09-11 (LTS).
  • Version 1.1.0 will be supported until 2019-09-11.
  • Version 1.0.2 will be supported until 2019-12-31 (LTS).
  • Version 1.0.1 is no longer supported.
  • Version 1.0.0 is no longer supported.
  • Version 0.9.8 is no longer supported.

We may designate a release as a Long Term Support (LTS) release. LTS releases will be supported for at least five years and we will specify one at least every four years. Non-LTS releases will be supported for at least two years.

During the final year of support, we do not commit to anything other than security fixes. Before that, bug and security fixes will be applied as appropriate.


Before a major release, we make a number of pre-releases, labeled alpha and beta.

An alpha release means:

  • Not (necessarily) feature complete
  • Not necessarily all new APIs in place yet

beta release means:

  • Feature complete/Feature freeze
  • Bug fixes only

For any major or minor release, we have defined the following release criteria:

  • All open github issues/PRs older than 2 weeks at the time of release need to be assessed for relevance to the version being released. Any flagged with the a milestone for the version to be released must be closed (see below).
  • Clean builds in Travis and Appveyor for two days.
  • run-checker.sh succeeds on 2 consecutive days before release.
  • No open Coverity issues (not flagged as "False Positive" or "Ignore").

Valid reasons for closing an issue/PR with a milestone for the version might be:

  • We have just now or sometime in the past fixed the issue
  • Unable to reproduce (following discussion with original reporter if possible)
  • Working as intended
  • Deliberate decision not to fix this issue until a later release (this wouldn't actually close the issue/PR but change the milestone instead)
  • Not enough information and unable to contact reporter

No API or ABI breaking changes are allowed in a minor or patch release. The following stability rules apply to all changes made to code targeted for a major release from version 3.0.0 or later:

  • No existing public interface can be modified except where changes are unlikely to break source compatibility or where structures are made opaque.
  • No existing public interface can be removed until its replacement has been in place in an LTS stable release. The original interface must also have been documented as deprecated for at least 5 years. A public interface is any function, structure or macro declared in a public header file.
  • When structures are made opaque, any newly required accessor macros or functions are added in a feature release of the extant LTS release and all supported intermediate successor releases.

猜你喜欢

转载自blog.csdn.net/qq2399431200/article/details/93600738