Kiedy zmieniasz numer wersji głównej / drobnej / poprawki?

Możliwa duplikat:
jakiej „konwencji nazewnictwa wersji” używasz?

Czy zmieniasz numer wersji głównej / drugorzędnej / łaty tuż przed wydaniem, czy tuż po?

Przykład: właśnie wydałeś 1.0.0 dla świata (huzzah!). Ale poczekaj, nie świętuj za dużo. 1.1.0 ukaże się za sześć tygodni! Naprawiasz błąd i robisz nową kompilację. Jak nazywa się ten build? 1.1.0.0 lub 1.0.0.xxxy (gdzie xxxy to inkrementacja numeru wersji 1.0.0)?

Pamiętaj, że możesz mieć 100 funkcji i błędów, aby przejść do wersji 1.1.0. Warto więc nazwać to 1.0.0.xxxy, ponieważ nie jesteś blisko 1.1.0. Ale z drugiej strony inny deweloper może pracować nad wersją 2.0.0, w którym to przypadku twoja kompilacja może mieć lepszą nazwę 1.1.0.0 i jego 2.0.0.0 zamiast odpowiednio 1.0.0.xxxy i 1.0.0.xxxz.

Po wydaniu oprogramowania numer wersji należy natychmiast zwiększyć.

Dlaczego?

Załóżmy, że postępujesz zgodnie ze schematem, takim jak Semantic Versioning , i masz numer wersji w wersji. Więc możesz mieć [Major]. [Minor]. [Patch]. [Build]. Zadzwonię do [Major]. [Minor]. [Patch] rozdzieli wersję.

Podczas tworzenia będziesz tworzyć wiele kompilacji. Każda kompilacja jest migawką rozwoju następnej wersji. Sensowne jest używanie tej samej wersji do kompilacji programistycznych i wydań. Wersja wskazuje, co zwalnia pracujesz kierunku .

Jeśli przygotowujesz się do wydania, a oprogramowanie przejdzie wszystkie testy, nie będziesz chciał przebudowywać i ponownie testować oprogramowania tylko dlatego, że musiałeś zaktualizować wersję. Kiedy ostatecznie wydasz wersję, oświadczasz, że „kompilacja 1.1.0.23” będzie odtąd nazywana „wersją 1.1.0”.

Model przyrostowy po zwolnieniu ma również sens dla rozgałęzień. Załóżmy, że masz główną gałąź programistyczną i tworzysz gałęzie obsługi dla wydań. W momencie tworzenia gałęzi wydania gałąź rozwoju nie jest już powiązana z numerem wersji tego wydania. Gałąź rozwoju zawiera kod będący częścią następnej wersji, więc wersja powinna to odzwierciedlać.

Ogólnie staram się używać SemVer do wewnętrznych numerów wersji. Miło jest wiedzieć coś o wydaniu opartym na semantyce jego numeru wersji.

Podczas programowania staram się od razu zmieniać numery wersji (jeśli to możliwe) . Czasami trudno jest ustalić, czy zmiana będzie przełomową, czy nie (co wpłynie na mój numer wersji), więc nic nie jest „osadzone w kamieniu”.

Aby zaadresować swój konkretny przykład:

• Podczas opracowywania wersje przedpremierowe byłyby 1.0.1-alpha.1, 1.0.1-alpha.2 itd.
• Ostateczna wersja poprawki to wersja 1.0.1.

Powiedziawszy to, numery wersji produktów „publicznych” są często ustalane przez marketing i są zupełnie inne. To jest poza moją kontrolą, więc nie ma co się o to martwić.

Załóżmy ABCD w odpowiedziach. Kiedy zwiększasz każdy z komponentów?

Zasadniczo zależy to od polityki firmy. Nasza polityka firmy to:

• A - Istotne (> 25%) zmiany lub uzupełnienia funkcjonalności lub interfejsu.
• B - niewielkie zmiany lub uzupełnienia funkcjonalności lub interfejsu.
• C - drobne zmiany, które psują interfejs.
• D - poprawki w kompilacji, które nie zmieniają interfejsu.

W większych projektach / organizacjach główne i drobne numery wersji są kontrolowane przez działy marketingu i zwykle są zwiększane ze względów marketingowych. W mojej organizacji grupy dążą do wydania jednego głównego i jednego mniejszego wydania każdego roku. Oczekuje się, że główne wersje będą zawierały nowe znaczące funkcje, a interfejsy API będą binarnie kompatybilne dla wszystkich wersji z tym samym głównym numerem wersji. Jednak marketing może zdecydować się na obniżenie poważnej zmiany wersji na niewielką, ponieważ obiecane funkcje nie są dostarczane lub odwrotnie, na przykład w celu przeskoczenia konkurencji żab.

Większe i mniejsze numery kompilacji (c i d w abcd) są zwykle kontrolowane przez rozwój. c to numer kompilacji, a d jest używany do poprawek do określonego wydania lub wersji c.

W twoim przypadku zmiana głównych i podrzędnych numerów wersji jest mniej istotna niż upewnienie się, że główne i podrzędne numery kompilacji są dokładne. W mojej organizacji zmieniamy główne i drobne numery kompilacji w ramach procesu rozgałęziania w kontroli źródła. Główny oddział zwykle zawiera najnowszą wersję, ale marketing mógł nie zdecydować, jaki numer wersji będzie miał jeszcze wydanie.

Staramy się podążać za przykładem Eclipse . Lepiej wyjaśnia niż ja, ale dla nas działa to tak:

Po wydaniu wersji 1.0.0.0 zmieniany numer wersji zależy od rodzaju wprowadzanej zmiany.

• Wersja, która nie ma wpływu na interfejs API, należy rozważyć poprawkę błędu za kulisami, która sprawia, że ​​bieżący interfejs API działa w oczekiwany sposób, jest wydawany w wersji 1.0.1
• Wydanie, które dodaje się do interfejsu API, ale nie zmienia istniejącego interfejsu API, mogła zostać dodana nowa funkcja, która nie czyni obecnych klientów nieporównywalnymi z nową wersją. Może to również obejmować dowolną liczbę powyższych poprawek.
• Wydanie psuje bieżący interfejs API, usuwając coś, zmieniając coś w sposób, który psuje porównywalność z bieżącymi klientami. Może to mieć także dowolną liczbę powyższych poprawek.

Jeśli chodzi o sposób wykorzystania czwartej sekcji numeru wersji, używamy tego do rozróżnienia różnych wersji w Nuget (rozwiązanie do zarządzania pakietami, którego używamy dla .net). Pozwala nam to uniknąć konieczności czyszczenia pamięci podręcznej za każdym razem, gdy potrzebujemy aktualizować nasze niepublikowane oprogramowanie.

Nie ma kolejnej wersji. W tej gałęzi.

Idealna wersja naszego programu.

Identyfikacja wersji w dowolnym oddziale to PRETTY_BRANCH_NAME-build, a PRETTY_BRANCH_NAME jest ustalany podczas tworzenia oddziału.

Nasz schemat rozgałęziania (*) jest następujący:

Oddziały najwyższego poziomu, PRETTY_BRANCH_NAME każdego z nich jest nazwą kodową, mówiąc o numerze wersji na tym poziomie jest bez znaczenia, może istnieć planowany schemat, ale zmieni się przed wydaniem.

• oddział TNG ( następnej generacji ), w którym dokonuje się długoterminowego rozwoju. Często nawet go nie mamy i nigdy nie ma (wydania) podzakresów.

• oddział TCG ( obecna generacja ), w którym dokonuje się bieżącego rozwoju. PRETTY_BRANCH_NAME to kryptonim.

• oddział TPG ( poprzednia generacja ). Często nie dokonuje się tutaj dalszego rozwoju, ale może istnieć aktywność w podobszarach.

Odgałęzienie składa się z odgałęzienia najwyższego poziomu (TCG, w obecności powolnej migracji TPG), gdy rozpoczyna się beta dla głównego wydania. PRETTY_BRANCH_NAME to coś w rodzaju „1.3.X” (X to litera, a nie cyfra, oznacza to, że zamierzamy dostarczyć stąd wersje 1.3), opinie z wersji beta są tutaj uwzględniane, podczas gdy praca nad kolejną ważną wersją jest zakończona oddział TCG.

Idealnie, wydanie powinno być migawką w tej gałęzi, ale wiemy, że nie jesteśmy doskonali i często musimy wprowadzać zmiany w ostatniej chwili, pozwalając innym na kontynuowanie pracy dla następnej mniejszej wersji. W ten sposób powstają podzbrania w celu ostatecznej stabilizacji, przy czym ładne nazwy są oficjalnym numerem wersji (w tym czasie nawet marketing nie będzie chciał go zmieniać), np. „1.3”, „1.3.1” z gałęzi „1.3.X”, ostatnia wersja każdego z nich to wydanie.

Gdybyśmy mieli czwarty poziom, nazwy podpoddziałów brzmiałyby „1.3.0.X”, z których mielibyśmy pod ^ 3 odgałęzienia „1.3.0.0” „1.3.0.1”.

(*) Na poziomie wydania. Na każdym z nich mogą znajdować się podobszary projektu.

Jeśli sprzedajesz oprogramowanie, będziesz mieć nowe główne wydanie za każdym razem, gdy sprzedaż / marketing będzie wymagał większej premii :-).

Jeśli masz kontrolę, to:

1. Najważniejsze wydania, gdy:

   • Istnieje pewna niezgodność z poprzednią wersją, która wymaga konwersji itp., Np. Z Python 2 na Python 3.

   • Istnieje cała masa nowych funkcji.

2. Drobne wydania dla wszelkich drobnych zmian w funkcjonalności.

3. Wydanie poprawki poprawek błędów.