发布流程

OAuthLib已经到了相当多的库和用户依赖它的地步。正因为如此，将引入更谨慎的发布程序，以确保所有这些可爱的项目不会突然破裂。

在临近发布时，我们将使用未发布的OAuthLib版本对一组下游库进行单元测试。如果OAuthLib是导致测试失败的原因，我们将：

找到一种在不中断下游的情况下引入变化的方法。然而，这并不总是最好的长期选择。
在受影响的项目问题跟踪器中报告突破性的更改，或者如果有许多项目受到影响，则通过Github在OAuthLib上的“主”问题中提及。

理想情况下，这个过程将允许快速而优雅的发布，但在下游项目长时间处于中断阶段的情况下，我们只建议他们将oauthlib版本锁定在 setup.py 不管怎样，还是要释放。

单元测试可能是不够的，作为额外的措施，我们将在Github发布之前至少2天在Github上创建一个OAuthLib发布问题，详细说明更改并ping每个下游项目的主要联系人。如果您有重大问题，请在这两天内回复。

如何进入通知列表

将在OAuthLibs中定义哪些项目和每个项目的测试说明 Makefile 。要添加您的项目，只需打开Pull请求或通过打开GitHub问题来通知您想要添加。还请包括GitHub用户，他们可以在Github中提到作为该项目的主要联系人。

下一次发布是什么时候？

发布充其量是零星的，我认为这种情况不会很快改变。然而，如果你认为是时候发布新的版本了，请毫不犹豫地打开新的一期询问它。

关于版本化的注记

从历史上看，OAuthLib在语义版本控制方面一直不是很好，但自2014年的1.0.0以来，这一点发生了变化。因为，任何主要的数字版本(例如2.0.0)都可能引入非向后兼容的更改。Minor Point(1.1.0)版本将引入非API突破性的新功能和更改。错误版本(1.0.1)将包括需要快速发布的次要修复(例如，在较大的版本无意中引入错误之后)。