Zobacz Drupal.org, aby uzyskać konwencje nazewnictwa wersji i dalsze objaśnienia .
Streszczenie:
rc = Release Candidate, uznany przez autora za odpowiedni dla zakładów produkcyjnych.
rc : Kandydat do wydania powinien zostać utworzony tylko wtedy, gdy zgłoszone zostaną wszystkie krytyczne problemy z typami błędów naprawione w kolejce problemów projektu. Tego tagu należy używać tylko wtedy, gdy deweloper uważa, że projekt jest gotowy do użycia w witrynie produkcyjnej. Nie ma oficjalnej najlepszej praktyki dotyczącej tego, jak długo projekt powinien być kandydatem do wydania przed utworzeniem oficjalnej wersji .0, ale sugeruje się, że powinien być dostępny przez co najmniej miesiąc, a status powinien być ustawiony na „wymaga przeglądu”. Jeśli coś (np. Zgłoszony zostanie nowy krytyczny błąd) powoduje, że konieczne jest utworzenie nowego wydania w tym okresie, należy utworzyć nowego kandydata do wydania, który powinien pozostać przez co najmniej miesiąc ze statusem ustawionym na „wymaga przeglądu”.
Można oznaczyć moduł „rc” nierozstrzygniętymi problemami z żądaniami funkcji. Autorzy modułów nie są zobowiązani do spełnienia każdego żądania funkcji użytkownicy postu modułu do kolejki problemów.
Oto opis innych dozwolonych tagów wydania:
niestabilny : projekt nie jest w stanie stabilnym. Prawdopodobnie jest wiele nierozwiązanych błędów, w tym problemów z bezpieczeństwem. Interfejs API może ulec zmianie bez powiadomienia. Schemat bazy danych może ulec zmianie bez hook_update_Nimplementacji. Użycie i interfejs API mogą nie być udokumentowane. Zainstalowanie nowej niestabilnej wersji pociąga za sobą odinstalowanie projektu, a tym samym utratę wszystkich danych. Tylko dla tych, którzy chcą wczesnego podglądu projektu. Nie nadaje się jeszcze do wspólnego rozwoju.
alfa : Większość zgłaszanych błędów jest rozwiązana, ale nadal mogą istnieć poważne nierozwiązane znane problemy, w tym problemy z bezpieczeństwem. Projekt nie jest dokładnie testowany, więc może być też wiele nieznanych błędów. Istnieje plik README.txt / README.md, który dokumentuje projekt i jego interfejs API (jeśli istnieje). Schemat API i DB może być ustabilizowany, ale wszystkie zmiany w nich są zgłaszane w uwagach do wydania i hook_update_Nsą implementowane w celu zachowania danych poprzez zmiany schematu, ale bez innej ścieżki aktualizacji / aktualizacji. Nie nadaje się do zakładów produkcyjnych. Docelowi odbiorcy to programiści, którzy chcą uczestniczyć w testowaniu, debugowaniu i rozwoju projektu.
beta : wszystkie krytyczne błędy związane z utratą danych i bezpieczeństwem zostały rozwiązane. Jeśli moduł oferuje interfejs API, należy go uznać za zamrożony, aby osoby korzystające z interfejsu API mogły rozpocząć aktualizację swoich projektów. Jeśli jest to aktualizacja lub aktualizacja projektu, należy zaoferować ścieżkę aktualizacji / aktualizacji, a istniejący użytkownicy powinni mieć możliwość aktualizacji / aktualizacji do nowej wersji bez utraty danych. Cała dokumentacja powinna być aktualna. Grupą docelową są programiści, którzy chcą uczestniczyć w testowaniu, debugowaniu i opracowywaniu projektu, oraz programiści innych projektów, które łączą projekt. Zasadniczo nie nadaje się do witryn produkcyjnych, ale może być stosowany w niektórych witrynach produkcyjnych, jeśli administrator witryny dobrze zna projekt i wie, jak poradzić sobie z pozostałymi problemami.
Ciągi „dev” i „stable” nie są poprawne jako część tagu release, ale zakłada się , że nieoznakowane wydania deweloperskie to „dev”, a Drupal otrzymuje takie opisy jak „7.x-1.x-dev” System pakowania wersji .org wskazujący, że są to nieoznaczone wersje rozwojowe.
Wszystkie tagi wydania muszą kończyć się liczbą. Liczby mają jedynie na celu rozróżnienie wydań tej samej klasy. Pierwszy jest ponumerowany „1” (jak w „alpha1”), następny „2” i tak dalej.
PS. Ciągi oznaczające wydania (takie jak „7.x-1.0-alpha4”) są znane jako „znaczniki wydania” w języku git, a nie „nazwy”. I nigdy nie używasz drupal minor w ramach tagu, zamiast tego używasz „x”.