Skąd pochodzi numer wersji?

Question

Mam system kontroli wersji (np. Subversion), a teraz chciałbym skonfigurować proces kompilacji. Teraz muszę utworzyć numer wersji i wstawić go do systemu. Ale skąd się bierze numer wersji i jak się do niej dostać? Załóżmy, że chcę użyć tego popularnego < głównych>. < minor>. < opis/korekta błędu. Czy powinienem przekazać numer do skryptu kompilacji? Czy powinienem przekazać argumenty takie jak increaseMajor, increaseMinor, increaseRevision? A może zaleca się utworzenie oddziału z numerem, który zostanie wykryty przez skrypt budujący?

Mogę sobie wyobrazić, że główny i podrzędny numer wersji muszą być wprowadzone gdzieś ręcznie. Numer wersji mógł zostać zwiększony automatycznie. Ale nadal nie wiem, gdzie będę umieszczać większą i mniejszą liczbę.

W moim przypadku mam pliki php, które chciałbym spakować, ale zanim będę musiał wstawić niektóre numery wersji do pliku php.

---

I edycja tego posta, aby spróbować zrobić mój wniosek jaśniej:

nie używam Subversion, to był tylko przykład. I nie chcę omawiać schematu numeru wersji.

Wyobraź sobie, że chcę utworzyć wersję 3.5.0 lub 3.5.1. Czy przekazałbym ten numer wersji do skryptu kompilacji? Czy skrypt utworzyłby gałąź w repozytorium z tym numerem, czy też oczekiwałby, że ktoś już utworzył tę gałąź? Ręcznie? Czy skrypt budujący mógłby szukać nazwy oddziału (np. "3.5.1") i używać go do dalszych czynności? I czy numer wersji pochodzi z mojego mózgu, czy jest automatycznie tworzony (myślę, że numer główny/pomocniczy pochodzi z mojego małego mózgu i powstaje numer rewizji)? Czy możesz umieścić numer w pliku, który może zostać wstawiony do repozytorium?

Zgaduję, że jeśli użyłbym narzędzia do zarządzania wersjami, wstawiłbym tam numer wersji. Ale jeszcze go nie używam.

Answer 1

W przypadku subwersji, weź numer globalnej wersji i użyj go jako numeru "kompilacji", a nawet lepiej, nie polegaj na nim w ogóle i zarządzaj wersjami z tagami i/lub oddziałami. Głównym problemem związanym z globalną rewizją jest dokładnie to, że jest to globalne dla repozytorium. Zwiększy się, nawet jeśli niektóre części repozytorium się nie zmienią.

Całkowicie oddzielić wersje od wersji repo jest IMHO lepsze. Masz tagi, użyj ich.

Answer 2

Wersja w svn lub innym systemie kontroli wersji to nie to samo, co numer wersji produktu (lub nawet numer kompilacji).

Istnieje wiele sposobów egzekwowania numeru wersji. Często w subwersji można utworzyć gałąź (lub znacznik, to w zasadzie to samo) dla kompilacji, a jeśli jest to wersja wydania, to tworzy się dla niej znacznik, np. Svn: //my-repo/releases/1.0.0

Możesz przekazać parametr do swojego skryptu budowania, aby uzyskać kod i użyć go jako numeru kompilacji lub mieć katalog, którego używał twój skrypt kompilacji, i svn przełączyć go do gałęzi, którą chcesz zbudować, skryptu może użyć informacji o svn, aby określić, którą wersję budował.

Answer 3

x.y.i.j 

Gdzie x - major wersja y - Mniejsza wersja i - numer kompilacji, j - liczba przyrostów kontrolne

Major version temat wielkich zmian (nowa architektura, nowe UI, etc)

Minor version przyrosty przy drobnych zmianach (poprawa wydajności, naprawianie błędów itp.),

Build number przyrosty co Czy robisz publiczne wydanie.

Revision number przyrosty za każdym razem, gdy użytkownik zatwierdza zmiany w drzewie źródłowym projektu.

Wolę punkcie 0 jako numer rewizji w AssemblyInfo.cs i wskazać rzeczywistą liczbę w nazwie pakietu uwalniania (foo-1.1.7.110-source.zip)

Answer 4

uzgodniony ze wszystkimi poprzednimi na wykorzystaniu gałęzie i znaczniki. Dodatkowo nazwy oddziałów i nazwy znaczników mogą być włączone do procesu budowania w/niektóre sprytne skrypty.

Jedyną ciekawostką, którą chcę dodać, jest to, że powinieneś podkraść wersję SVN do każdej kompilacji. Czasami łatwo jest wrócić do określonego punktu w wersji zamiast znać tag lub gałąź. 99% tag/branch jest wystarczająco dobre, ale wersja jest świetna dla przyrostowych/wewnętrznych/ciągłych/testowych buildów.

Answer 5

Wszystkie gałęzie należy tworzyć ręcznie. Skrypt budujący powinien działać poza znacznikiem i/lub odgałęzieniem, zaczynając od sprawdzenia (lub może je aktualizować). W ramach procesu budowania warto utworzyć znacznik na dokładnie utworzonej migawce.

Normalnie masz numer kompilacji i wersję. Numer kompilacji może być automatycznie zwiększany i sprawdzany w kontroli wersji jako część kompilacji (z wyjątkiem budowania opartego na znacznikach, gdzie numer kompilacji musi pozostawać poza repozytorium - kolejny powód, aby unikać budowania opartych na znacznikach).

Wersja jest zwykle przechowywana w pliku aktualizowanym ręcznie raz na cykl wydania. Sprawdzono go w gałęzi Thight, a następnie zostawiono w spokoju. Na przykład główna linia miałaby w swoim pliku wersję = "3", pierwsza wersja w gałęzi wydania miała wersję = "3.5", a jeśli potrzebna jest poprawka, oddzielasz ją od gałęzi wydania i sprawdza wersję = "3.5.1"