Answers:
有关发布命名约定和 进一步移植的信息，请参阅Drupal.org 。
摘要：
rc =版本候选，作者认为适合生产现场。
rc：仅当在项目的发布队列中报告了所有严重的bug类型问题都已修复时，才应该创建候选发布版本。仅当开发人员认为该项目已准备好在生产站点上使用时，才应使用此标记。在创建正式的.0版本之前，没有正式的最佳实践可以说明项目应该成为发布候选版本的时间，但是建议将项目至少发布一个月，并将状态设置为“需要审查”。如果在此期间有必要（例如，报告了一个新的严重错误）创建了一个新版本，则应创建一个候选新版本，并将其保留至少一个月，并将状态设置为“需要审核”。
可以用未解决的功能请求标记模块“ rc”。不需要模块作者来满足模块的每个功能请求用户将其发布到发布队列中。
这是其他允许的发布标签的描述：
不稳定：项目处于不稳定状态。可能存在许多未修复的错误，包括安全问题。API可能会更改，恕不另行通知。数据库架构可能会更改，而不会hook_update_N实现。用法和API可能没有记录在案。安装新的不稳定版本需要卸载项目，从而丢失所有数据。仅适用于那些希望早期预览项目的人。尚不适合共享开发。
alpha：大多数已报告的错误已解决，但仍然可能存在严重的未解决的已知问题，包括安全问题。该项目没有经过彻底的测试，因此可能还会存在许多未知的错误。有一个README.txt / README.md记录了项目及其API（如果有）。API和DB模式可能是可用的，但是对它们的所有更改都在发行说明中进行了报告，并hook_update_N实现为通过模式更改来保留数据，但没有其他升级/更新路径。不适合生产现场。目标受众是希望参与项目测试，调试和开发的开发人员。
beta：解决了所有重要的数据丢失和安全性错误。如果模块提供了API，则应将其视为已冻结，以便使用该API的人员可以开始升级其项目。如果是项目的升级或更新，则应提供升级/更新路径，并且现有用户应该可以升级/更新到新版本而不会丢失数据。所有文档均应为最新。目标受众是希望参与项目测试，调试和开发的开发人员，以及与该项目连接的其他项目的开发人员。通常不适合生产站点，但是如果站点管理员非常了解项目并知道可以处理任何剩余问题，则可以在某些生产站点上使用。
字符串“ dev”和“ stable”作为发行标签的一部分无效，但是未加标签的开发版本被假定为“ dev”，Drupal给出了诸如“ 7.x-1.x-dev”之类的描述。 .org发布打包系统，指示它们是未标记的开发版本。
所有发行标签必须以数字结尾。这些数字仅是为了区分同一类的发行版。第一个编号为“ 1”（如“ alpha1”中所示），第二个编号为“ 2”，依此类推。
PS。在git术语中，表示发布的字符串（例如“ 7.x-1.0-alpha4”）被称为“发布标签”，而不是“名称”。而且，您永远不要将drupal 次要版本用作标签的一部分，而应使用“ x”。