Jak działają wczesne numery wersji dla nowych produktów?

Obecnie piszę małą aplikację komputerową dla przyjaciela, ale robię to przede wszystkim jako doświadczenie edukacyjne. W duchu zdobywania wykształcenia i robienia rzeczy we właściwy sposób chcę mieć numery wersji tej aplikacji.

Moje badania przyniosły te powiązane wyniki

• Jakiej „konwencji nazewnictwa wersji” używasz?
• Jak oceniasz swoje pliki (Numery wersji)
• Opracowałem projekt, od czego zaczynają się moje numery wersji?

ale żadne z nich nie zajmuje się numeracją alf, bet, kandydatów do wydania itd. Jakie są konwencje dla numerów wersji poniżej 1.0? Wiem, że mogą trwać przez jakiś czas; na przykład PuTTY istnieje już od co najmniej dekady i wciąż jest dostępny tylko w wersji beta 0.60.

To naprawdę zależy od projektu; niektóre projekty nawet nie wydają wersji 1.0.

Twórcy MAME nie zamierzają wypuszczać wersji 1.0 swojego programu emulującego. Argument polega na tym, że nigdy nie będzie tak naprawdę „ukończony”, ponieważ zawsze będzie więcej gier zręcznościowych. Po wersji 0.99 następowała po prostu wersja 0.100 (mniejsza wersja 100> 99). W podobny sposób po Xfire 1.99 nastąpił 1.100. Po 6 latach rozwoju eMule nie osiągnął jeszcze wersji 0.50. ^{Wersjonowanie oprogramowania z Wikipedii}

Jedną z popularnych metod numerowania wersji (z których zacząłem korzystać) jest wersja semantyczna .

W ramach tego schematu numery wersji i sposób ich zmiany przekazują znaczenie dotyczące kodu źródłowego i tego, co zostało zmodyfikowane z jednej wersji do następnej.

Kilka cytatów, aby dać ci więcej pomysłów na to, jak to działa i / lub odpowiedzieć na niektóre pytania:

Skąd mam wiedzieć, kiedy wydać 1.0.0?

Jeśli twoje oprogramowanie jest używane w środowisku produkcyjnym, prawdopodobnie powinno to być już 1.0.0. Jeśli masz stabilny interfejs API, od którego zaczęli polegać użytkownicy, powinieneś mieć wersję 1.0.0. Jeśli bardzo martwisz się kompatybilnością wsteczną, prawdopodobnie powinieneś już mieć wersję 1.0.0.

Czy nie zniechęca to do szybkiego rozwoju i szybkiej iteracji?

W głównej wersji zero chodzi o szybki rozwój. Jeśli zmieniasz interfejs API codziennie, powinieneś być nadal w wersji 0.xx lub w oddzielnym oddziale programistycznym pracującym nad kolejną wersją główną.

Jeśli nawet najmniejsze wstecznie niezgodne zmiany w publicznym interfejsie API wymagają poważnego wypaczenia wersji, czy nie skończę w wersji 42.0.0 bardzo szybko?

Jest to kwestia odpowiedzialnego rozwoju i prognozowania. Niekompatybilne zmiany nie powinny być lekko wprowadzane do oprogramowania, które ma dużo zależnego kodu. Koszt, który musi zostać poniesiony na uaktualnienie, może być znaczny. Konieczność zderzenia głównych wersji w celu wydania niezgodnych zmian oznacza, że ​​przemyślisz wpływ swoich zmian i ocenisz związany z nimi stosunek kosztów do korzyści.

Istnieją również zasady określania wersji „alfa”, „beta” itp. Sprawdź szczegóły na http://semver.org/ .

[Edytuj] Kolejnym interesującym schematem numeracji wersji jest ten, którego używa MongoDB :

MongoDB używa wersji nieparzystych w wydaniach programistycznych.

Istnieją 3 numery w wersji MongoDB: ABC

• A jest główną wersją. To rzadko się zmienia i oznacza bardzo duże zmiany
• B jest numerem wydania. Obejmuje to wiele zmian, w tym funkcje i rzeczy, które mogą zepsuć zgodność wsteczną. Nawet Bs będą stabilnymi gałęziami, a nieparzyste Bs będą rozwojem.
• C jest numerem wersji i będzie używany w przypadku błędów i problemów związanych z bezpieczeństwem.

Na przykład:

• 1.0.0: pierwsze wydanie GA
• 1.0.x: poprawki błędów do 1.0.x - wysoce zalecane do aktualizacji, bardzo małe ryzyko
• 1.1.x: wersja rozwojowa. obejmie to nowe funkcje, które nie są w pełni ukończone i są w trakcie realizacji. Niektóre rzeczy mogą być inne niż 1.0
• 1.2.x: drugie wydanie GA. będzie to kulminacja wydania 1.1.x.

Nie wydaje mi się, że istnieje „standard” jako taki.

Istnieje konwencja dla Release Candidates, która zwykle brzmi „[wersja] RC 1” itd. W zależności od liczby wersji, które według ciebie możesz wydać.

Jeśli wypuszczasz bardzo wczesną wersję swojego produktu - tę, która nie jest kompletna - możesz wybrać wersję „0”. W ten sposób możesz zwiększać wersję wraz z upływem czasu, wypełniając zestaw funkcji.

Użyłbym znaków „Alpha” i „Beta”, takich jak Release Candidate - w przypadku wersji ograniczonych czasowo, aby zasygnalizować, że uważasz, że jesteś bliski wydania pełnej wersji.

Istnieje wersja Wikipedii na temat wersji oprogramowania . W przypadku udostępniania wersji wcześniejszych niż 1.0 konwencja stosowana przez Apple i inne działa dobrze: major.minor.maintSrev gdzie S jest wskaźnikiem etapowym dla wersji wstępnych: d = programowanie, a = alfa, b = beta, rc = kandydat do wydania. Twoja pierwsza wersja wewnętrzna może mieć wersję 1.0.0d1.

W przypadku wersji całkowicie wewnętrznych znacznik czasu jest wystarczający.

Każdy programista w większości decyduje o tym, jakiego standardu będzie używać. Zasadniczo jednak liczby po lewej stronie przecinka dziesiętnego wskazują duże poprawki, które prawdopodobnie byłyby bardzo zauważalne dla przeciętnego użytkownika (tj. Zmiany funkcjonalności lub interfejsu itp.). Po prawej stronie przecinka dziesiętnego byłaby to zmiana / modyfikacja / dodatek, która nie zmieniła zbytnio ogólnej funkcjonalności i projektu, ale zmieniła coś w samym programie (tj. Przyspieszyła funkcję, wciąż robiąc to samo lub naprawiła problem bezpieczeństwa). Następnie, jeśli dodasz dodatkowe miejsca po przecinku, liczby po prawej stronie będą oznaczać coraz mniejsze zmiany (np. Drobne poprawki błędów / problemy bezpieczeństwa i tym podobne).

Jak powiedzieli inni, wydaje się, że nie ma dokładnego standardu. Nasza organizacja stosuje następującą notację:

Wersja 1.0 ---> 2.0 (Do produktu dodano istotną nową / ulepszoną funkcję)

Wersja 1.0 ---> 1.1 (Do produktu dodano nową / ulepszoną funkcję średniego poziomu)

Wersja 1.0 ---> 1.001 (poprawki błędów)

Kamień milowy „wersja 1.0” jest bardzo ważny dla doświadczonych użytkowników komputerów, ponieważ oznacza, że ​​program został wykonany i działa zgodnie z oczekiwaniami. Cokolwiek w wersji „0. coś” sugeruje, że sami programiści uważają, że program jeszcze się nie skończył .

Możesz zachować numery wersji „0.1”, „0.2” ... dla głównych osiągnięć funkcjonalności, a następnie poddzielić go numerem kompilacji, który często jest wystarczająco precyzyjną datą i znacznikiem czasu.