Czym dokładnie jest numer kompilacji w MAJOR.MINOR.BUILDNUMBER.REVISION

Myślę o numerach kompilacji, że za każdym razem, gdy tworzona jest nowa kompilacja nocna, generowany jest nowy BUILDNUMBER i przypisywany do tej kompilacji. Tak więc dla mojej wersji wersji 7.0 kompilacje nocne to 7.0.1, 7.0.2 i tak dalej. Czy tak jest W takim razie jaki jest pożytek ZMIANY po numerze kompilacji? Czy też część ZMIANY jest zwiększana po każdej nocnej kompilacji? Jestem tu trochę zdezorientowany ... czy każdą nocną kompilację nazywamy BUDYNKIEM ?

Format jest wymieniony tutaj: AssemblyVersion - MSDN

Nigdy nie widziałem tego napisanego w takiej formie. Tam, gdzie pracuję, używamy formularza MAJOR.MINOR.REVISION.BUILDNUMBER, gdzie MAJOR to główne wydanie (zwykle wiele nowych funkcji lub zmian w interfejsie użytkownika lub bazowym systemie operacyjnym), MINOR to niewielkie wydanie (być może niektóre nowe funkcje) na poprzednia główna wersja, REVISION jest zazwyczaj poprawką do poprzedniej mniejszej wersji (brak nowej funkcjonalności), a wartość BUILDNUMBER jest zwiększana dla każdej najnowszej wersji poprawki.

Na przykład wersja może zostać wydana do QA (kontrola jakości) i wrócą z problemem, który wymaga zmiany. Błąd zostanie naprawiony i wydany z powrotem do kontroli jakości z tym samym numerem WERSJI, ale z przyrostem BUILDNUMBER.

Całe zamieszanie wynika z innej semantyki stosowanej przez MS w odniesieniu do „numeru kompilacji”, a zwłaszcza „rewizji”. Terminy po prostu oznaczają różne rzeczy.

Większość ludzi (w tym ja) używa semantycznego schematu numeracji wersji, w którym po prostu dostajesz wyższy numer BUILD, ilekroć musisz stworzyć nową kompilację z jakiegokolwiek powodu. Dla nas poprawka jest uważana za kolejną zmianę kodu, a część BUILD rośnie automatycznie przy każdym uruchomieniu CI. Moduły z tym samym MAJ.MIN.REV są uważane za wymienne, a BUILD informuje, który z nich jest najnowszy.

Zwiększenie REWIZJI wskazuje jednak na nową gałąź stałego wydania, dlatego umieszczamy ją przed BUDOWANIE. Minusem tego podejścia jest to, że możemy uzyskać następującą sekwencję zdarzeń:

• zatwierdzić numer 4711: Alice dodała funkcję A
• CI tworzy kompilację 1.2.3.100
• zatwierdzić numer 4712: zmodyfikowana funkcja B Boba
• zatwierdzić numer 4713: Alice naprawiła funkcję A („poprawkę”)
• CI tworzy kompilację 1.2.3.101

Jak widać, poprawka nie jest jedyną zmianą zawartą w następnej kompilacji, również modyfikacja Boba staje się częścią tej kompilacji. Jeśli chcesz ustabilizować obecną gałąź, możesz wpaść w kłopoty, ponieważ nigdy nie możesz być pewien, czy Bob właśnie dodał kilka błędów.

MS stosuje oba terminy w różny sposób. Numer BUILD nie jest automatycznie zwiększany, zamiast tego można go uznać za rodzaj gałęzi wydania, w celu zamrożenia kodu używanego dla konkretnej wersji kodu. REWIZJA wskazuje dodatkowe „gorące” zmiany zastosowane do tego oddziału BUILD. Sekwencja byłaby zatem następująca:

• zatwierdzić numer 4711: Alice dodała funkcję A do trunk / master
• Carl tworzy gałąź kompilacji 1.2.100
• CI tworzy kompilację 1.2.100.0
• zatwierdzić numer 4712: Bob zmodyfikował cechę B w trunk / master
• zatwierdzić numer 4713: Alice naprawiła funkcję A w 1.2.100gałęzi
• CI tworzy kompilację 1.2.100.1

Termin REWIZJA może odnosić się do

• produkt rewizja (tak jak większość ludzi go używać)
• rewizja konkretnej codziennej wersji (właśnie to robi MS)

Kluczowa różnica między tymi dwoma procesami polega na tym, czy chcesz mieć możliwość zastosowania poprawek do kompilacji CI, a tym samym, w którym momencie procesu tworzona jest gałąź. Ten aspekt staje się ważny, gdy chcesz wybrać konkretną kompilację w dowolnym momencie po pomyślnym zakończeniu wszystkich testów i promować dokładnie tę wersję do następnej oficjalnej wersji Twojego produktu.

W naszym przypadku narzędzie CI tworzy znacznik repozytorium, więc zawsze mamy niezbędne informacje gotowe do użycia w razie potrzeby. Dzięki SVN staje się to jeszcze prostsze, ponieważ tagi i gałęzie są implementowane dokładnie w ten sam sposób - tag jest niczym więcej niż gałęzią znajdującą się pod /tags.

Zobacz też

W sekcji FAQ strategii rozgałęziania TFS :

W jakiej gałęzi powinienem naprawić bilet P1 (poprawka)?

• P1 powinien zostać ustalony w gałęzi najbliższej bazie kodu działającej w dziale produkcyjnym. W takim przypadku P1 należy naprawić w gałęzi Prod. Stosując poprawkę w dowolnym innym oddziale i wdrażając zmiany w produkcji, ryzykujesz zwolnieniem niedokończonego lub nieprzetestowanego kodu z kolejnych iteracji.

• Teraz możesz spierać się, czy można bezpiecznie pracować bezpośrednio przeciwko gałęzi Prod, pomyśl jeszcze raz, P1, który wymaga natychmiastowej uwagi, nie powinien być podstawowym problemem w systemie. Jeśli jest to podstawowy problem, należy go dodać do rejestru produktu, ponieważ może on wymagać dalszej analizy i dyskusji z klientem.

Kolejną dobrą lekturą jest przewodnik rozgałęziający TFS

Microsoft opisuje przeznaczenie każdego składnika numeru wersji .NET w dokumentacji MSDN dla tej Versionklasy. Oto odpowiednia część:

major.minor [.build [.revision]]

Komponenty są używane zgodnie z konwencją w następujący sposób:

Major: Zespoły o tej samej nazwie, ale różne główne wersje nie są zamienne. Wyższy numer wersji może wskazywać na poważne przepisanie produktu, w przypadku którego nie można założyć kompatybilności wstecznej.

Drobne: Jeśli nazwa i główny numer wersji na dwóch zestawach są takie same, ale podrzędny numer wersji jest inny, oznacza to znaczące ulepszenie z intencją wstecznej kompatybilności. Ten wyższy, mniejszy numer wersji może wskazywać na wydanie produktu lub w pełni kompatybilną z poprzednią wersją produktu.

Kompilacja: Różnica w liczbie kompilacji oznacza rekompilację tego samego źródła. Różne numery kompilacji mogą być używane, gdy zmienia się procesor, platforma lub kompilator.

Wersja: Zespoły o tej samej nazwie, głównych i mniejszych numerach wersji, ale różne wersje mają być w pełni zamienne. W kompilacji, która naprawia lukę bezpieczeństwa we wcześniej wydanym zestawie, można użyć wyższego numeru wersji.

http://msdn.microsoft.com/en-us/library/system.version.aspx

Mogę sobie wyobrazić co najmniej kilka różnych rzeczy, do których odwołuje się numer kompilacji:

1. Wersja kontroli źródła, która została wydana. Na przykład, jeśli pojawiła się wersja wersji 12345, można to prześledzić, wpisując numer kompilacji, a jeśli zostanie ona załatana, to tam mogą pojawić się poprawki, ponieważ nie jest to nowa funkcjonalność, która zwiększyłaby główne lub mniejsze wersje i numer kompilacji musi zostać zapamiętany na wypadek, gdyby ktoś chciał uruchomić tę kompilację ponownie.

2. Identyfikator serwera ciągłej integracji. W takim przypadku serwer CI może numerować każdą uruchomioną kompilację, a zatem numer kompilacji jest tym, co otrzymuje kompilacja zakończona sukcesem i w tym scenariuszu nie jest potrzebna część zmiany.

Mogą istnieć inne, których nie znam, ale są to te duże, które znam, jeśli chodzi o liczby na podstawie kodu.

Numer kompilacji jest zwykle zwiększany przy każdej kompilacji, więc jest unikalny.

Dla uproszczenia niektórzy resetują numer kompilacji za każdym razem, gdy numery MAJOR lub MINOR są podbijane.

Większość silników ciągłej integracji pozwala na automatyczne generowanie unikalnych numerów kompilacji.

Wersja może być używana do poprawek kompilacji. Powiedzmy, że 2 zespoły pracują nad produktem.

Zespół 1 jest głównym zespołem programistów i tworzy kompilację nocną w następującym schemacie wersji 1.0.X.0, w której X jest zwiększany. Teraz są w kompilacji 1.0.50.0. Zespół 2 wykonuje kompilację od czasu do czasu. Powiedzmy, że biorą kompilację z ostatniego tygodnia, czyli 1.0.43.0 i zaczynają ją używać. Zespół 1 przechodzi do wersji 1.0.51.0, gdy zespół 2 znajdzie problem w wersji 1.0.43.0.

Teraz zespół 1 weźmie tę kompilację (43), napraw problem i przekaż drużynie 2 kompilację 1.0.43.1. Poprawka może być również propagowana w głównej wersji, więc zmiana pojawi się w wersji 1.0.52.0.

Mam nadzieję, że to jasne i pomocne.

* Wersja jest przydatna, gdy nie wszyscy zaangażowani w projekt korzystają z tej samej kompilacji i trzeba załatać określone kompilacje.

Pozwól mi tylko powiedzieć, jak to widzę i używam ...

Wersja programu nazwa major.minor.build.revision

major: Dla mnie jest obecny projekt, nad którym pracuję. Liczba nie zmieni się, dopóki nie rozpocznę nowego projektu o tej samej nazwie programu. Oznacza to, że dosłownie napiszę nowy program tej samej płci (przykład: access v1 - access v-2 - access v-3 * wszystkie ten sam program, ale całkowicie przepisany).

minor: Oznacza to, że dodam funkcjonalność do aktualnie opublikowanego projektu. Na przykład może dodałem możliwość wydrukowania paragonu lub możliwość importowania zdjęć. Zasadniczo dodatkowa funkcjonalność, którą chcę teraz dodać i nie czekam na następną główną wersję.

kompilacja: używam do wskazania bardzo małych zmian w opublikowanej wersji major.minor. Może to być zmiana układu, schematu kolorów itp.

wersja: Używam tego, aby wskazać naprawę błędu w bieżącym opublikowanym major.minor.build - Są sytuacje, w których nie rozwijam bieżącego projektu i pojawia się błąd. Ten błąd należy naprawić i opublikować. To po prostu oznacza, że ​​naprawiam to, co już opublikowałem, aby działało poprawnie. Użyłbym tego również, jeśli pracuję nad nową wersją, nowym dodatkiem lub uruchomiłem nową wersję główną. Opublikowana wersja oczywiście musi zostać załatana, gdy czekamy na następne wydanie główne, drobne lub kompilacyjne.

W ten sposób gotowy lub zatrzymany projekt może być nadal naprawiony i użyteczny do czasu opublikowania następnego wydania.

Mam nadzieję, że dzięki temu ktoś lepiej zrozumie, w jaki sposób ten typ wersjonowania mógłby (lub powinien) działać. Dla mnie jest to jedyna definicja i praktyka, która ma jakikolwiek sens podczas używania tego typu wersjonowania.

Widziałem tylko numer kompilacji jako ostatni numer w identyfikatorze wydania. Nie jestem pewien, jak wymyślisz poprawkę do numeru kompilacji. Podejrzewam, że jeśli zmieniłeś niektóre niezbudowane zasoby (ikony, skrypt DB itp.), Być może, ale większość projektów, nad którymi pracowałem ostatnio, ma również wszystkie te elementy pod kontrolą wersji, więc proces kompilacji odbiera je, gdy wykonanie instalatora / wydania. Lubię numery kompilacji ze znacznikami czasu, choć nie do końca tak, jak opisuje to @David (lubię major.minor.revision.HHMM). Jednak tam, gdzie pracuję, używamy po prostu numeru sekwencyjnego generowanego przez nasz serwer kompilacji.

Podobnie jak jkohlhepp, używamy trzeciej części wersji, aby wyświetlić numer wersji w SubVersion, a czwartej, aby wyświetlić numer kompilacji z naszego serwera ciągłej integracji (dla nas Jenkins). Daje to nam kilka korzyści - ustawienie numeru wersji przez nasz serwer CI usuwa ręczny krok, który w innym przypadku mógłby zostać przypadkowo pominięty; łatwo sprawdzić, czy programista nie wydał bezczelnej wersji ze swojego komputera programistycznego (co spowodowałoby, że te liczby byłyby zerowe); i pozwala nam powiązać dowolne oprogramowanie z kodem, z którego został wygenerowany, i zadaniem CI, które go zbudowało, po prostu patrząc na numer wersji - co czasami okazujemy się bardzo przydatne.

Jest czymkolwiek chcesz. Zwykle używam year.month.day.hhmm do mojej ważnej.minor.budowy.budowy. Jeśli produkuję więcej niż jedną minutę, coś jest nie tak. możesz po prostu użyć prostego przyrostu lub widziałem dla nich kilka skomplikowanych generatorów. Czego ty chcesz go mieć. Muszą zrobić to, abyś dostał się do źródła użytego do stworzenia tego wyniku, więc cokolwiek pozwala ci to zrobić.

Dwie ostatnie cyfry to całkowita liczba kompilacji

1.01.2.1234

numer kompilacji to 2.1234, jednak większość ludzi po prostu użyje 1234, ponieważ 2 część nie zmienia się często.

Nasz zespół używa trzeciego numeru (rewizji) jako numeru rewizji z repozytorium Subversion. Używamy czwartej liczby (kompilacji) jako numeru kompilacji z naszego serwera ciągłej integracji TeamCity, który faktycznie tworzy kompilację. TeamCity tworzy nowy plik AssemblyInfo z odpowiednimi #s podczas procesu kompilacji.