Risposte:
Vedi Drupal.org per le convenzioni di denominazione dei rilasci e ulteriori spiegazioni .
Sommario:
rc = Release Candidate, ritenuto idoneo dall'autore per i siti di produzione.
rc : Un candidato al rilascio deve essere creato solo quando tutti i problemi critici relativi al tipo di bug vengono segnalati risolti nella coda dei problemi del progetto. Questo tag deve essere utilizzato solo quando lo sviluppatore ritiene che il progetto sia pronto per l'uso in un sito di produzione. Non esiste una migliore pratica ufficiale per quanto tempo un progetto dovrebbe essere un candidato al rilascio prima di creare un rilascio ufficiale .0, ma si suggerisce che dovrebbe essere fuori per almeno un mese con lo stato impostato su "revisione delle esigenze". Se qualcosa (ad esempio viene segnalato un nuovo bug critico) rende necessario creare una nuova versione durante questo periodo, è necessario creare una nuova versione candidata che dovrebbe rimanere per almeno un mese con lo stato impostato su "Revisiona necessità".
È corretto contrassegnare un modulo "rc" con problemi di richieste di funzionalità in sospeso. Gli autori dei moduli non sono tenuti a soddisfare ogni richiesta di funzionalità degli utenti del post del modulo nella coda di emissione.
Ecco una descrizione degli altri tag di rilascio consentiti:
instabile : il progetto non è in uno stato stabile. Probabilmente ci sono numerosi bug non corretti, inclusi problemi di sicurezza. L'API può cambiare senza preavviso. Lo schema del database può cambiare senza hook_update_Nessere implementato. L'utilizzo e l'API potrebbero non essere documentati. L'installazione di una nuova versione instabile comporta la disinstallazione del progetto, con conseguente perdita di tutti i dati. Solo per chi desidera un'anteprima anticipata del progetto. Non ancora adatto allo sviluppo condiviso.
alfa : la maggior parte degli errori segnalati sono stati risolti, ma potrebbero esserci ancora gravi problemi noti in sospeso, inclusi problemi di sicurezza. Il progetto non è stato testato a fondo, quindi potrebbero esserci anche molti bug sconosciuti. Esiste un file README.txt / README.md che documenta il progetto e la sua API (se presente). Lo schema API e DB può essere utilizzabile, ma tutte le modifiche apportate sono riportate nelle note di rilascio e hook_update_Nsono implementate per preservare i dati attraverso le modifiche dello schema, ma nessun altro percorso di aggiornamento / aggiornamento. Non adatto a siti di produzione. Destinatari sono gli sviluppatori che vogliono partecipare ai test, al debug e allo sviluppo del progetto.
beta : tutti i bug critici relativi alla perdita di dati e alla sicurezza sono stati risolti. Se il modulo offre un'API, dovrebbe essere considerato congelato, in modo che coloro che utilizzano l'API possano iniziare ad aggiornare i propri progetti. Se si tratta di un aggiornamento o aggiornamento di un progetto, dovrebbe essere offerto un percorso di aggiornamento / aggiornamento e dovrebbe essere possibile per gli utenti esistenti aggiornare / aggiornare alla nuova versione senza perdita di dati. Tutta la documentazione dovrebbe essere aggiornata. Destinatari sono gli sviluppatori che vogliono partecipare ai test, il debug e lo sviluppo del progetto e gli sviluppatori di altri progetti che interfacciano il progetto. Generalmente non adatto a siti di produzione, ma può essere utilizzato su alcuni siti di produzione se l'amministratore del sito conosce bene il progetto e sa gestire eventuali problemi rimanenti.
Le stringhe "dev" e "stabili", non sono validi come parte di un tag liberatoria, ma senza tag versioni di sviluppo si presume siano "dev" e sono dati descrizioni quali "7.x-1.x-dev" da parte del Drupal .org release packaging system per indicare che sono versioni di sviluppo senza tag.
Tutti i tag di rilascio devono terminare con un numero. I numeri servono solo per distinguere le versioni della stessa classe. Il primo è numerato "1" (come in "alpha1"), il successivo "2" e così via.
PS. Le stringhe che indicano rilasci (come "7.x-1.0-alpha4") sono note come "tag di rilascio" in git parlance, non "nomi". E non usi mai la versione secondaria drupal come parte di un tag, invece usi "x".