답변:
릴리스 이름 지정 규칙 및 추가 explantion에 대해서는 Drupal.org를 참조하십시오 .
요약:
rc = 출시 후보, 제작 사이트 제작자에게 적합한 것으로 간주됩니다.
rc : 릴리스 후보는 모든 중요 버그 유형 문제가 프로젝트의 이슈 큐에서 수정 된 것으로보고 된 경우에만 작성해야합니다. 이 태그는 개발자가 프로젝트가 프로덕션 사이트에서 사용할 준비가되었다고 판단 할 때만 사용해야합니다. 공식 .0 릴리스를 작성하기 전에 프로젝트가 릴리스 후보 여야하는 기간에 대한 공식적인 모범 사례는 없지만 상태가 "검토 필요"로 설정된 상태에서 최소 한 달 동안 프로젝트를 중단해야합니다. 이 기간 동안 무언가 (예 : 새로운 중요 버그가보고 된 경우) 새 릴리스를 작성해야하는 경우 새 릴리스 후보를 작성해야하며 상태가 "검토 필요"로 설정된 상태에서 최소 한 달 동안 유지되어야합니다.
기능 요청 문제가있는 모듈 "rc"에 태그를 지정해도됩니다. 모듈 작성자는 모듈 포스트의 모든 기능 요청 사용자를 이슈 큐에 이행하지 않아도됩니다.
허용되는 다른 릴리스 태그에 대한 설명은 다음과 같습니다.
불안정 : 프로젝트가 안정 상태가 아닙니다. 보안 문제를 포함하여 수정되지 않은 수많은 버그가있을 수 있습니다. API는 예고없이 변경 될 수 있습니다. 데이터베이스 스키마는 hook_update_N구현 되지 않고 변경 될 수 있습니다 . 사용법 및 API가 문서화되어 있지 않을 수 있습니다. 새로운 불안정한 릴리스를 설치하면 프로젝트가 제거되어 모든 데이터가 손실됩니다. 프로젝트의 초기 미리보기를 원하는 사람들에게만 해당됩니다. 공유 개발에는 아직 적합하지 않습니다.
alpha :보고 된 대부분의 오류가 해결되었지만 보안 문제를 포함하여 아직 알려진 심각한 문제가 여전히있을 수 있습니다. 프로젝트는 철저히 테스트되지 않았으므로 알려지지 않은 많은 버그가있을 수도 있습니다. 프로젝트와 해당 API를 문서화하는 README.txt / README.md가 있습니다 (있는 경우). API 및 DB 스키마는 사용 가능할 수 있지만 이에 대한 모든 변경 사항은 릴리스 정보에보고되며 hook_update_N스키마 변경을 통해 데이터를 보존하기 위해 구현되지만 다른 업그레이드 / 업데이트 경로는 없습니다. 생산 현장에는 적합하지 않습니다. 대상 독자는 프로젝트의 테스트, 디버깅 및 개발에 참여하려는 개발자입니다.
베타 : 모든 중요한 데이터 손실 및 보안 버그가 해결되었습니다. 모듈이 API를 제공하는 경우 API를 사용하는 사용자가 프로젝트 업그레이드를 시작할 수 있도록 고정 된 것으로 간주해야합니다. 프로젝트의 업그레이드 또는 업데이트 인 경우 업그레이드 / 업데이트 경로를 제공해야하며 기존 사용자가 데이터 손실없이 새 버전으로 업그레이드 / 업데이트 할 수 있어야합니다. 모든 문서는 최신 상태 여야합니다. 대상 독자는 프로젝트의 테스트, 디버깅 및 개발에 참여하려는 개발자 및 프로젝트를 인터페이스하는 다른 프로젝트의 개발자입니다. 일반적으로 프로덕션 사이트에는 적합하지 않지만 사이트 관리자가 프로젝트를 잘 알고 나머지 문제를 처리하는 경우 일부 프로덕션 사이트에서 사용할 수 있습니다.
문자열 "dev"및 "stable"은 릴리스 태그의 일부로 유효하지 않지만 태그가없는 개발 릴리스는 "dev"인 것으로 가정하고 Drupal에서 "7.x-1.x-dev"와 같은 설명을 제공합니다. .org 릴리스 패킹 시스템은 태그가없는 개발 릴리스임을 나타냅니다.
모든 릴리스 태그는 숫자로 끝나야합니다. 숫자는 동일한 클래스의 릴리스를 구별하기위한 것입니다. 첫 번째는 "1"( "alpha1"에서처럼), 다음은 "2"등으로 번호가 매겨집니다.
추신. 릴리스를 나타내는 문자열 (예 : "7.x-1.0-alpha4")은 "이름"이 아닌 자식 용어로 "릴리스 태그"로 알려져 있습니다. 그리고 drupal 부 버전을 태그의 일부로 사용하지 말고 대신 "x"를 사용하십시오.