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

Nigdy nie widziałem tego napisanego w takiej formie. Tam, gdzie pracuję, używamy formularza MAJOR.MINOR.REVISION.BUILDNUMBER, gdzie:

• MAJOR to wersja główna (zwykle wiele nowych funkcji lub zmian w interfejsie użytkownika lub podstawowy system operacyjny)
• MNIEJSZE to wydanie drugorzędne (być może jakieś nowe funkcje) w stosunku do poprzedniej wersji głównej
• REVISION jest zwykle poprawką dla poprzedniej wersji pomocniczej (brak nowych funkcji)
• BUILDNUMBER jest zwiększana dla każdej najnowszej kompilacji zmiany.

Na przykład, wersja może zostać wydana do kontroli jakości (kontrola jakości) i powracają z problemem, który wymaga zmiany. Błąd zostałby naprawiony i wydany z powrotem do kontroli jakości z tym samym numerem REVISION, ale zwiększonym BUILDNUMBER.

Komentarze

• +1: że ' jest prawie taki sam, jak ' widziałem to wszędzie indziej. ' widziałem i spodobało mi się, jak niektóre firmy używają po prostu znacznika daty i godziny jako BUILDNUMBER.
• +1: ” MAJOR.MINOR.REVISION.BUILDNUMBER ” forma jest zrozumiała i ma sens. Widziałem formularz BUILDNUMBER.REVISION w witrynie MSDN (odnośnik zaktualizowany w pytaniu) i całkowicie mnie to zmyliło.
• Dziwne. Spodziewałbym się, że najbardziej sensowna będzie ostatnia wersja – to ' to numer, który (prawdopodobnie) zmieni się najbardziej.
• @Izkata, a właściwie kompilacja liczba zmienia się najbardziej, a przynajmniej sposób, w jaki używamy go w moim głównym kontrakcie w tej chwili, w którym obowiązuje ścisła kontrola wersji, ponieważ produkujemy urządzenia medyczne. Zaktualizowana wersja wskazuje, że do poprzedniego oprogramowania została wprowadzona poprawka, która musi zostać przetestowana przez QA (Quality Assurance). Jest to całkowicie oddzielny dział, który przeprowadza obszerne testy przez trzy dni (zgodnie z wytycznymi FDA). Jeśli znajdą jakieś problemy, mogą być konieczne dodatkowe zmiany kodu wymagające nowej kompilacji (ponownej kompilacji i linku), a następnie ponownego przetestowania, ale numer wersji pozostaje taki sam.
• @tcrosley Myślę, że to to przypadek niejasnej terminologii. Myślałem o zmianach w kontroli wersji.

Całe zamieszanie wynika z różne semantyki , których MS używa dla „numeru kompilacji”, a zwłaszcza „wersji”. Terminy mają po prostu różne znaczenie.

Większość ludzi (łącznie ze mną) używa semantycznego schematu numerowania wersji , w którym uzyskuje się po prostu wyższy numer BUILD za każdym razem, gdy z jakiegokolwiek powodu musisz stworzyć nową wersję. Dla nas poprawka jest uważana za kolejną zmianę kodu, a część BUILD zwiększa się automatycznie z każdym uruchomieniem CI. Moduły z tym samym MAJ.MIN.REV są uważane za zamienne, a BUILD informuje, który z nich jest najnowszy.

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

• numer zatwierdzenia 4711: Alicja dodała funkcję A
• CI tworzy kompilację 1.2.3.100
• numer zatwierdzenia 4712: Bob zmodyfikował funkcję B
• numer zatwierdzenia 4713: Alice naprawiła funkcję A („poprawka”)
• CI tworzy kompilację 1.2.3.101

Jak widać, poprawka nie jest jedyną zmianą zawartą w następnym build, również modyfikacje Boba stają się częścią tej kompilacji. Jeśli chcesz ustabilizować bieżącą gałąź, możesz napotkać problemy, ponieważ nigdy nie możesz być pewien, czy Bob właśnie dodał kilka błędów.

MS używa obu terminów inaczej. Numer BUILD nie jest automatycznie zwiększany, zamiast tego można go uznać za rodzaj gałęzi wydania, aby zamrozić kod używany dla określonej wersji kodu. REVISION wskazuje na dodatkowe „gorące” zmiany zastosowane do tej gałęzi BUILD. Sekwencja byłaby zatem następująca:

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

Termin REVISION może odnosić się do

• a produktu wersja (tak właśnie używa jej większość ludzi)
• wersja określonej codziennej kompilacji (to właśnie robi MS)

Kluczową różnicą między tymi dwoma procesami jest to, czy chcesz mieć możliwość stosowania poprawek do kompilacji CI, czy też nie, w którym momencie procesu powstaje gałąź. Ten aspekt staje się ważny, gdy chcesz móc wybrać konkretną kompilację w dowolnym momencie po pomyślnym zakończeniu wszystkich testów i promować dokładnie tę wersję do następnego oficjalnego wydania swojego produktu.

W naszym przypadku narzędzie CI tworzy tag repozytorium, więc zawsze mamy niezbędne informacje gotowe do użycia, gdy są potrzebne. Z SVN staje się to jeszcze prostsze, ponieważ tagi i gałęzie są implementowane dokładnie w ten sam sposób – tag to nic innego jak gałąź znajdująca się pod /tags.

Zobacz także

Z sekcji FAQ pod adresem Strategia rozgałęziania TFS :

W której gałęzi mam naprawić bilet P1 (poprawka)?

• P1 powinien zostać naprawiony w gałęzi, która jest najbliższa bazie kodu działającej w środowisku produkcyjnym. W takim przypadku P1 powinien zostać naprawiony w gałęzi Prod. Stosując poprawkę w dowolnej innej gałęzi i wprowadzając zmiany w środowisku produkcyjnym, ryzykujesz wypuszczenie częściowo ukończonego lub nieprzetestowanego kodu z kolejnych iteracji.

• Teraz możesz się spierać, czy tak jest bezpieczna praca bezpośrednio przeciwko gałęzi Prod, pomyśl jeszcze raz, P1 wymagający 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 wymagać dalszej analizy i dyskusji z klientem.

Kolejną dobrą lekturą jest Przewodnik po rozgałęzieniach TFS

Komentarze

• To świetna odpowiedź! +1

Firma Microsoft opisuje cel każdego składnika numeru wersji .NET w swojej dokumentacji MSDN dla klasy Version. Oto odpowiednia część:

major.minor [.build [.revision]]

Komponenty są używane zgodnie z konwencją następujące:

Główny: zestawy o tej samej nazwie, ale różne wersje główne 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ć zgodności z poprzednimi wersjami.

Drugorzędny: Jeśli nazwa i główny numer wersji w dwóch zespołach są takie same, ale pomocniczy numer wersji jest inny, wskazuje to na znaczące ulepszenie z zamiarem kompatybilności wstecznej. Wyższy numer wersji pomocniczej może wskazywać na wydanie punktowe produktu lub w pełni kompatybilną wstecz nową wersję produktu.

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

Rewizja: zestawy o tej samej nazwie, głównych i pomocniczych numerach wersji, ale różne wersje mają być w pełni zamienne. Wyższy numer wersji może być użyty w kompilacji, która naprawia lukę w zabezpieczeniach we wcześniej wydanym zespole.

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

Komentarze

• Wprawia mnie w zakłopotanie, dlaczego nikt nie zna tego standardu. Każda odpowiedź tutaj twierdzi, że kompilacja kończy się na końcu i nie ' t rozumiem, że wersja jest bardzo prosta; to znaczy poprawka. Wydajesz kompilację, a następnie tworzysz kolejne kompilacje, ale kiedy musisz cofnąć się i naprawić to wydanie, aktualizujesz wersję, aby pokazać, że konkretna wydana kompilacja została zmieniona dla nowej wersji
• +1 dla odpowiedź, która ma uzasadniony numer kompilacji. Samo zwiększanie liczby jest raczej bezużyteczne, jeśli wersja pozostaje taka sama (chyba że masz szalony system kompilacji, który jest zależny od czasu). Użycie numeru kompilacji do zasygnalizowania, który kompilator, platformy itp. jest przydatne.
• Build jako recompilation of the same source wydaje się być ważnym punktem, który jest pomijany. Jeśli ' to zmiana kodu (to ' nie wymaga zupełnie nowego dużego / małego zwiększenia), to Revision należy również zmienić.
• @PeterX Jak w przypadku zmian specyficznych dla kompilacji podczas ponownego kierowania?
• ” Różnica w numerze kompilacji reprezentuje ponowną kompilację tego samego źródła ” wydaje się być sprzeczna z dokumentacją. Po wprowadzeniu poprawki nie jest to już to samo źródło. BUILD przed REVISION ma sens tylko wtedy, gdy wersja jest specyficzna dla kompilacji reprezentującej ” zmianę procesora, platformy lub kompilatora „. Więc myślę, że to, co większość osób postrzega jako uderzenie REWIZJI, powinno naprawdę być MNIEJSZYM uderzeniem podczas korzystania z tych opisów. Chociaż dokumenty wspominają o używaniu REVISION dla poprawek, ale zakładam, że poprawki będą miały zastosowanie do wszystkich kompilacji, a zatem powinny być MNIEJSZY. Chcę tylko logicznej spójności !!

Jest przynajmniej kilka różnych rzeczy, które mógłbym wyobraź sobie numer kompilacji odnoszący się do:

1. Wersja kontroli źródła, która została wydana. Na przykład, jeśli pojawiło się wydanie wersji # 12345, można to śledzić, podając numer kompilacji, a jeśli jest poprawiony, zmiany mogą się zwiększać, ponieważ nie jest to nowa funkcja, która zwiększyłaby wersje główne lub pomocnicze i numer kompilacji należy zapamiętać na wypadek, gdyby ktoś chciał ponownie uruchomić tę kompilację.

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 uzyskuje pomyślna kompilacja, a część poprawiająca nie jest potrzebna w tym scenariuszu.

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

Komentarze

• +1 za nr 1. Lubię używać wersja kontroli źródła #, ponieważ znacznie ułatwia wyszukiwanie błędów zgłoszonych w tej wersji w kontroli źródła.
• @MasonWheeler: działa świetnie, jeśli korzystasz z SVN. Ale kiedy dostaniesz się do dcvs, dostaje wiewiórkę y. To jest jedna rzecz, której najbardziej brakuje mi w svn I ' ll add.

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 wartości MAJOR lub MINOR są zmieniane.

Większość silników Continuous Integration pozwala na automatycznie generowane unikalne numery kompilacji.

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

Zespół 1 jest głównym zespołem programistycznym i tworzy nocne kompilacje z następującym schematem wersji 1.0.X.0, w którym X jest zwiększany. Teraz są w wersji 1.0.50.0. Zespół 2 od czasu do czasu tworzy kompilację. Powiedzmy, że biorą kompilację z zeszłego tygodnia, czyli 1.0.43.0 i zaczynają ją używać. Drużyna 1 przechodzi do wersji 1.0.51.0, gdy zespół 2 napotka problem w wersji 1.0.43.0.

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

Mam nadzieję jest to jasne i pomocne.

* Rewizja jest przydatna, gdy nie wszyscy zaangażowani w projekt używają tej samej kompilacji i musisz załatać określone kompilacje.

Pozwólcie, że powiem tylko, jak go widzę i używam ….

Wersja programu nazwa programu major.minor.build.revision

major: Dla mnie to bieżący projekt, nad którym pracuję. Numer nie zmieni się, dopóki nie rozpocznę nowego projektu o tej samej nazwie programu. Oznacza to, że dosłownie będę pisać nowy program tej samej płci (przykład: access v1 – access v-2 – uzyskaj dostęp do v-3 * do tego samego programu, ale całkowicie przepisanego).

drobne: Oznacza to, że jestem reklamą ding funkcjonalność do aktualnie publikowanego projektu.Na przykład może dodałem możliwość drukowania paragonu lub dodałem możliwość importu zdjęć. Zasadniczo dodatkowa funkcjonalność, którą chcę teraz dodać i nie czekać na następną główną wersję, aby to zrobić.

build: Używam tego do wskazania bardzo małych zmian w opublikowanej wersji major.minor. Może to być zmiana w układzie, schemacie kolorów itp.

wersja: Używam tego, aby wskazać poprawkę błędu w aktualnie opublikowanym pliku major.minor.build – są sytuacje, w których nie rozwijam aktualny projekt i pojawia się błąd. Ten błąd należy naprawić i opublikować. Oznacza to po prostu, że poprawiam to, co już opublikowałem, aby działało poprawnie. Użyłbym tego również, jeśli pracuję nad nową kompilacją, nowym dodatkiem lub uruchomiłem nową wersję główną. Opublikowana wersja oczywiście musi zostać poprawiona, gdy czekamy na następną wersję główną, poboczną lub kompilacyjną.

W ten sposób ukończony lub zatrzymany projekt może być nadal naprawiany i używany do następnego wydania. opublikowane.

Mam nadzieję, że to da komuś lepsze zrozumienie tego, jak ten typ wersjonowania będzie (lub powinien) działać. Dla mnie jest to jedyna definicja i praktyka, która ma jakikolwiek sens podczas korzystania z tego typu wersjonowania.

Widziałem tylko numer kompilacji jako ostatni numer w identyfikatorze wydania. Nie jestem pewien, jak wymyśliłeś poprawkę numeru kompilacji. Przypuszczam, że gdybyś zmienił niektóre niezbudowane zasoby ( ikony, skrypt bazy danych itp.), być może, ale większość projektów, nad którymi ostatnio pracowałem, ma również wszystkie te rzeczy pod kontrolą wersji, więc proces budowania wybiera je podczas tworzenia instalatora / wydania. Lubię numery kompilacji ze znacznikami czasu, chociaż nie do końca tak, jak opisuje @David (lubię major.minor.revision.HHMM). Jednak tam, gdzie pracuję, używamy po prostu kolejnego numeru, który generuje nasz serwer kompilacji.

To jest to, czego chcesz że jest to. Zwykle używam year.month.day.hhmm do mojej wersji major.minor.build.build. Jeśli produkuję więcej niż minutę, coś jest nie tak. możesz po prostu użyć prostego przyrostu lub widziałem dla nich kilka wyszukanych generatorów. Ty chcesz, żeby to był. Muszą zrobić to, abyś dostał się do źródła utwórz to wyjście, więc cokolwiek Ci to umożliwi.

Nasz zespół używa trzeciej liczby (rewizji) jako numer wersji z repozytorium Subversion. Czwarty numer (kompilacja) jest używany jako numer kompilacji z naszego serwera ciągłej integracji TeamCity, który faktycznie tworzy kompilację. Podczas procesu kompilacji TeamCity tworzy nowy plik AssemblyInfo z odpowiednimi #s. / p>

Podobnie jak jkohlhepp, używamy trzeciej części wersji do pokazania numeru wersji w SubVersion, a czwartej do pokazania numer kompilacji z naszego serwera ciągłej integracji (dla nas Jenkins). Daje nam to kilka korzyści – posiadanie numeru wersji ustawionego przez nasz serwer CI eliminuje ręczny krok, który mógłby być przypadkowo brakowało; łatwo jest sprawdzić, czy programista nie wydał bezczelnej wersji swojego komputera deweloperskiego (co spowodowałoby, że te liczby byłyby zerowe); i pozwala nam powiązać dowolne oprogramowanie z powrotem zarówno z kodem, z którego zostało ono wygenerowane, i zadaniem CI, które go zbudowało, po prostu patrząc na numer wersji – co czasami uważamy za bardzo przydatne.

Ostatnie dwie cyfry to łączny numer kompilacji

1.01.2.1234

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

Komentarze

• OP pyta, jaki jest numer kompilacji, a nie numer kompilacji w identyfikatorze wersji.