Respostas:
Veja Drupal.org para convenções de nomenclatura de versões e mais explicações .
Resumo:
rc = Release Candidate, considerado adequado pelo autor para os locais de produção.
rc : Um candidato a lançamento deve ser criado apenas quando todos os problemas críticos do tipo de bug forem relatados corrigidos na fila de problemas do projeto. Essa tag deve ser usada apenas quando o desenvolvedor acreditar que o projeto está pronto para uso em um site de produção. Não há uma prática recomendada oficial por quanto tempo um projeto deve ser um candidato a lançamento antes de criar um lançamento oficial .0, mas sugere-se que ele permaneça por pelo menos um mês com o status definido como "precisa revisar". Se algo (por exemplo, um novo bug crítico for relatado) tornar necessário criar uma nova versão durante esse período, um novo candidato à versão deve ser criado e isso deve permanecer por pelo menos um mês com o status definido como "precisa revisar".
Não há problema em marcar um módulo "rc" com problemas de solicitações de recursos pendentes. Os autores do módulo não são obrigados a atender todas as solicitações de recursos que os usuários postam no módulo na fila de problemas.
Aqui está uma descrição das outras tags de liberação permitida:
instável : O projeto não está em um estado estável. Provavelmente existem vários bugs não corrigidos, incluindo problemas de segurança. A API pode mudar sem aviso prévio. O esquema do banco de dados pode mudar sem ser hook_update_Nimplementado. O uso e a API podem não estar documentados. Instalar uma nova versão instável implica desinstalar o projeto, perdendo todos os dados. Somente para quem deseja uma prévia do projeto. Ainda não é adequado para desenvolvimento compartilhado.
alfa : A maioria dos erros relatados foi resolvida, mas ainda pode haver problemas conhecidos pendentes graves, incluindo problemas de segurança. O projeto não foi completamente testado; portanto, também pode haver muitos erros desconhecidos. Há um README.txt / README.md que documenta o projeto e sua API (se houver). O esquema da API e do banco de dados pode ser utilizável, mas todas as alterações são relatadas nas notas de versão e hook_update_Nimplementadas para preservar os dados por meio de alterações no esquema, mas nenhum outro caminho de atualização / atualização. Não é adequado para locais de produção. O público-alvo são desenvolvedores que desejam participar de testes, depuração e desenvolvimento do projeto.
beta : todos os erros críticos de perda de dados e segurança foram resolvidos. Se o módulo oferecer uma API, ela deverá ser considerada congelada, para que os usuários da API possam começar a atualizar seus projetos. Se for uma atualização ou atualização de um projeto, um caminho de atualização / atualização deve ser oferecido e deve ser possível que os usuários existentes atualizem / atualizem para a nova versão sem perda de dados. Toda a documentação deve estar atualizada. O público-alvo são desenvolvedores que desejam participar de testes, depuração e desenvolvimento do projeto e desenvolvedores de outros projetos que fazem interface com o projeto. Geralmente não é adequado para sites de produção, mas pode ser usado em alguns sites de produção se o administrador do site conhece bem o projeto e sabe lidar com os problemas restantes.
As strings "dev" e "stable" não são válidas como parte de uma tag de lançamento, mas os lançamentos de desenvolvimento sem marcação são assumidos como "dev" e recebem descrições como "7.x-1.x-dev" pelo Drupal .org liberar sistema de empacotamento para indicar que são liberações de desenvolvimento sem marcação.
Todas as tags de lançamento devem terminar com um número. Os números são apenas para distinguir lançamentos da mesma classe. O primeiro é numerado "1" (como em "alpha1"), o próximo "2" e assim por diante.
PS. As strings que denotam lançamentos (como "7.x-1.0-alpha4") são conhecidas como "tags de lançamento" na linguagem git, não em "nomes". E você nunca usa a versão secundária do drupal como parte de uma tag, usa "x".