Development
OpenTSDB 在 Producing 运行 TSD 的用户群不断壮大。还有许多才华横溢的开发人员为 OpenTSDB 创建工具或直接向项目贡献代码。如果您有兴趣通过添加新功能，修复错误，添加工具或仅更新文档来提供帮助，请阅读以下指南。然后签署贡献者协议并向我们发送请求请求！
如果您希望将 OpenTSDB 与您的应用程序集成，则已编译的 JAVA 库具有一致且记录良好的 API。请参阅JAVA API 文档。
Guidelines
-
请检查是否有人发布了错误后提交GitHub 上的问题。确保您的错误报告包含足够的详细信息，以便其他人可以轻松理解并快速修复。
-
阅读开发页面以获取提示
-
贡献代码的最佳方法是在 GitHub 上派生主仓库和发送请求请求。
-
错误修复应在
master分支中完成- 新功能或重大更改应在
next分支中完成
- 新功能或重大更改应在
-
或者，您可以将纯文本补丁发送到mailing list。
-
在可以包含您的代码更改之前，请提交贡献许可协议。
-
与 Apache 软件基金会不同，我们不需要将每个代码更改都附加到问题上。随意发送所需的许多小补丁。
-
请将您的更改分解为尽可能小的提交。
-
请尊重您要更改的代码的编码风格。
-
缩进代码，带有 2 个空格，没有制表符
-
将代码保持在 80 列
-
与
if，for，while等位于同一行的大括号 -
变量需要描述性名称
like_this(而不是典型的 Java 样式likeThis) -
以小写字母开头的名为
likeThis()的方法 -
名为
LikeThis的类，以大写字母开头 -
尽量使用
final关键字，尤其是在方法参数和 return 语句中。 -
尽可能避免检查异常
-
始终向类和成员提供最严格的可见性
-
Javadoc 您所有的类和方法。有些人直接使用 Java API，我们将为该站点构建文档，因此越多越好
-
除非绝对必要，否则请勿将依赖项添加到核心 OpenTSDB 库中
-
为您创建的任何类/方法添加单元测试，并确认所做的更改不会破坏现有的单元测试。我们知道 UT 不好玩，但它们很有用
-
Git Repository
OpenTSDB 在GitHub中维护。分支机构数量有限，每个分支机构的用途如下：
-
maintenance-这是以前发行的 OpenTSDB 版本，通常是最后一个次要版本。例如。如果当前版本为 2.3.0 或 2.3.1，则maintenance将具有最新的 2.2.x 版本。该分支应该很少有 PR 指向它。可以选择适用于以前版本的master补丁。 -
master-OpenTSDB 的当前发行版。只能针对master给出具有错误修复的请求请求。合并足够的 PR 后，我们将剪切另一个 PATCH 版本，例如 2.2.0 至 2.2.1. 具有新功能或行为修改的修补程序应指向next。针对 master 的补丁应精选到下游分支。 -
next-这是 OpenTSDB 的下一个次要发行版本，其中包含开发中的代码，或者，当该版本标记为 RC 时，则包含候选代码。如果版本标记为 SNAPSHOT，则可以将新功能应用于下一个。一旦移至 RC，则应针对put分支发布新功能。否则，仅应为 RC 代码提供错误修复。 -
put-当next分支处于 RC 状态时，应将新功能应用于put，它将是下一个次要版本。 -
X.0-OpenTSDB 的下一个主要版本，可能包括重大的 API 更改。当代码处于相当稳定的状态时，它将提升为 RC 的next，然后提升为master正式发布。
任何其他分支都可能在某个时候被修剪，因为它们可能包含过时的代码或临时的 hack。
