it-swarm-eu.dev

Jaké přesně je číslo sestavení v MAJOR.MINOR.BUILDNUMBER.REVISION

Co si myslím o sestavení čísel, je to, že kdykoli je vytvořeno nové noční sestavení, je vygenerován nový BUILDNUMBER a přiřazen k tomuto sestavení. Takže pro moji verzi 7.0 bude noční budování 7.0.1, 7.0.2 a tak dále. Je to tak? Jaké je tedy použití REVIZE po čísle sestavení? Nebo se část REVIZE zvyšuje po každé noční výstavbě? Jsem trochu zmatený zde ... máme na mysli každou noční sestavení jako [~ # ~] sestavení [~ # ~] ?

Formát je uveden zde: AssemblyVersion - MSDN

56
A9S6

Nikdy jsem to neviděl napsaný v této podobě. Tam, kde pracuji, používáme formulář MAJOR.MINOR.REVISION.BUILDNUMBER, kde MAJOR je hlavní vydání (obvykle mnoho nových funkcí nebo změn uživatelského rozhraní nebo základního OS), MINOR je menší verze (možná některé nové funkce) na předchozí hlavní verze, REVIZE je obvykle oprava předchozího menšího vydání (žádná nová funkce) a BUILDNUMBER se zvyšuje pro každou poslední sestavení revize.

Například může být vydána revize QA (kontrola kvality) a vrátí se s problémem, který vyžaduje změnu. Chyba by byla opravena a uvolněna zpět do QA se stejným číslem REVIZE, ale s přírůstkem BUILDNUMBER.

58
tcrosley

Celý zmatek pramení z odlišné sémantiky , kterou MS používá pro „Číslo sestavení“ a zejména „Revize“. Pojmy znamenají pouze různé věci.

Většina lidí (včetně mě) používá sémantické schéma číslování verzí , kde stačí získat vyšší číslo BUILD, kdykoli musíte z jakéhokoli důvodu provést novou sestavení. Oprava hotfix je pro nás považována pouze za další změnu kódu a část BUILD se automaticky zvyšuje s každým spuštěním CI. Moduly se stejným MAJ.MIN.REV jsou považovány za zaměnitelné a BUILD vám řekne, který z nich je nejnovější.

Zvýšení revize však naznačuje novou větev trvalého vydání, proto ji umístíme před BUILD. Nevýhodou tohoto přístupu je, že bychom mohli získat následující sled událostí:

  • odevzdat číslo 4711: Alice přidala funkci A
  • CI vytváří sestavení 1.2.3.100
  • odevzdat číslo 4712: Bob změněn prvek B
  • commit číslo 4713: Alice opravena funkce A („oprava hotfix“)
  • CI produkuje sestavení 1.2.3.101

major.minor.revision.build

Jak vidíte, oprava hotfix není jedinou změnou obsaženou v dalším sestavení, a také Bobova modifikace se stane součástí tohoto sestavení. Pokud chcete stabilizovat současnou větev, můžete narazit na potíže, protože si nikdy nemůžete být jisti, zda Bob právě přidal spoustu chyb.

MS používá oba termíny odlišně. Číslo BUILD není automaticky zvyšováno, namísto toho může být považováno za druh větev vydání, aby zmrazil kód používaný pro konkrétní verzi kódu. REVIZE označuje další „horké“ změny aplikované na danou větev BUILD. Posloupnost by tedy byla následující:

  • odevzdat číslo 4711: Alice přidala funkci A do kufru/pána
  • Carl vytvoří sestavení pobočky 1.2.100
  • CI produkuje sestavení 1.2.100.0
  • potvrzení číslo 4712: Bob změnil funkci B v kufru/masteru
  • odevzdat číslo 4713: Alice opravila funkci A v 1.2.100 větev
  • CI vytváří sestavení 1.2.100.1

major.minor.build.revision

Pojem REVIZE se může vztahovat

  • a product revision (that's how most people use it)
  • revize konkrétního denního sestavení (to je to, co dělá MS)

Klíčovým rozdílem mezi těmito dvěma procesy je to, zda chcete nebo nemůžete použít opravy hotfix na sestavení CI, a tedy v jakém okamžiku v procesu je větev vytvořena. Tento aspekt se stává důležitým, pokud chcete mít možnost vybrat konkrétní sestavu kdykoli poté, co všechny testy uspěly, a povýšit přesně tuto verzi na další oficiální vydání vašeho produktu.

V našem případě nástroj CI vytvoří značku úložiště, takže vždy máme potřebné informace připravené k použití, v případě potřeby. Se SVN je to ještě jednodušší, protože značky a větve jsou implementovány přesně stejným způsobem - značka není nic víc než větev umístěná pod /tags.

Viz také

Z části FAQ na strategie větvení TFS :

V jaké větvi bych měl opravit lístek P1 (hotfix)?

  • P1 by měl být opraven ve větvi, která je nejblíže k kódové základně běžící ve výrobě. V tomto případě by měl být P1 stanoven ve větvi Prod. Při použití opravy v jakékoli jiné větvi a zavádění změn ve výrobě riskujete uvolnění polotovaru nebo netestovaného kódu z následujících iterací.

  • Nyní můžete argumentovat, že je bezpečné pracovat přímo proti pobočce Prod, zamyslete se znovu, P1, který vyžaduje okamžitou pozornost, by neměl být základním problémem v systému. V případě, že se jedná o zásadní problém, měl by být přidán do produktového backlogu, protože může vyžadovat další analýzu a diskusi se zákazníkem.

Další dobré čtení je průvodce větvením TFS

20
JensG

Společnost Microsoft popisuje účel každé součásti čísla verze .NET ve své dokumentaci MSDN pro třídu Version. Zde je příslušná část:

major.minor [.build [.revision]]

Složky se běžně používají takto:

Major: Sestavy se stejným názvem, ale různé hlavní verze nejsou zaměnitelné. Vyšší číslo verze může znamenat hlavní přepis produktu, u kterého nelze předpokládat zpětnou kompatibilitu.

Menší: Pokud je název a číslo hlavní verze na dvou sestavách stejné, ale menší číslo verze je odlišné, znamená to významné zlepšení s cílem zpětné kompatibility. Toto vyšší vedlejší číslo verze může znamenat okamžité vydání produktu nebo plně zpětně kompatibilní novou verzi produktu.

Sestavení: Rozdíl v počtu sestavení představuje překompilaci stejného zdroje. Při změně procesoru, platformy nebo kompilátoru lze použít různá čísla sestavení.

Revize: Sestavy se stejným názvem, hlavní a menší verzí, ale různé revize jsou zamýšleny jako plně zaměnitelné. Vyšší číslo revize může být použito v sestavení, které opravuje bezpečnostní díru v dříve vydané sestavě.

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

17
Cole Campbell

Existuje přinejmenším několik různých věcí, které bych si dokázal představit s číslem sestavení odkazujícím:

  1. Verze řízení zdroje, která byla vydána. Například pokud došlo k vydání revize # 12345, může to být sledováno tím, že je to číslo sestavení a pokud je opraveno, je to místo, kde mohou revize jít nahoru, protože to není nová funkce, která by zvýšila hlavní nebo menší verze a číslo sestavení je třeba si pamatovat v případě, že někdo chce tuto sestavu znovu spustit.

  2. Identifikátor serveru pro kontinuální integraci. V tomto případě může server CI počítat každou sestavení, která se spouští, a proto je číslo sestavení tím, co úspěšné sestavení získá a v tomto scénáři není nutná revizní část.

Mohou existovat další, které nevím, ale to jsou ta velká, která vím, pokud jde o čísla na kódových základnách.

4
JB King

Číslo sestavení se obvykle zvyšuje při každém sestavení, takže je jedinečné.

Z důvodu jednoduchosti někteří resetují číslo sestavení, kdykoli se narazí na MAJOR nebo MINOR čísla.

Většina nepřetržitých integračních motorů umožňuje automaticky generovaná jedinečná čísla sestavení.

3
user1249

Revizi lze použít pro opravy sestavení. Řekněme, že na týmu pracují 2 týmy.

Tým 1 je hlavní vývojový tým a produkuje noční sestavení s následující verzí schématu 1.0.X.0, kde X se zvyšuje. Nyní jsou v sestavení 1.0.50.0. Tým 2 se čas od času staví. Řekněme, že berou sestavení z minulého týdne, což je 1.0.43.0, a začnou jej používat. Tým 1 postupuje na 1.0.51.0, když tým 2 najde problém v 1.0.43.0.

Nyní tým 1 vezme toto sestavení (43), opraví problém a poskytne týmu 2 sestavení 1.0.43.1. Oprava může být také propagována v hlavním sestavení, takže změna se objeví v 1.0.52.0.

Doufám, že je to jasné a užitečné.

* Revize je užitečná, když ne každý, kdo je zapojen do projektu, používá stejnou sestavení a je třeba oprava konkrétních sestav.

2
Victor Hurdugaci

Dovolte mi jen říci, jak to vidím a používám ....

ProgramName version major.minor.build.revision

major: Pro mě je aktuální projekt, na kterém pracuji. Číslo se nezmění, dokud nezačnu nový projekt se stejným názvem programu. To znamená, že budu doslova psát nový program stejného pohlaví (příklad: access v1 - access v-2 - access v-3 * všechny stejné programy, ale úplně přepsané).

menší: To znamená, že přidávám funkčnost do aktuálně publikovaného projektu. Například jsem možná přidal možnost tisknout účtenku nebo přidal možnost importovat obrázky. V zásadě další funkce, které chci přidat nyní, a nečekat na příští hlavní vydání, aby to udělalo.

build: Toto používám k označení velmi malých změn v publikované verzi major.minor. Může to být změna v rozvržení, barevném schématu atd.

revize: Tímto označuji opravu chyby v aktuálně publikovaném major.minor.build - Existují případy, kdy neprogresuji aktuální projekt a dojde k chybě. Tato chyba musí být opravena a zveřejněna. Znamená to jen, že opravuji to, co jsem již publikoval, aby správně fungoval. Použil bych to také, pokud pracuji na novém sestavení, novém přírůstku nebo na začátku nové hlavní verze. Publikovaná verze musí být zjevně opravena, zatímco čekáme na další hlavní, menší nebo build verzi.

Tímto způsobem může být hotový nebo zastavený projekt stále opraven a použitelný až do zveřejnění dalšího vydání.

Doufám, že to někomu poskytne lepší pochopení toho, jak by tento typ verzí fungoval (nebo měl) fungovat. Pro mě je to jediná definice a praxe, která při použití tohoto typu verzí dává jakýkoli typ skutečného smyslu.

2
Richard Rindom

Jako poslední číslo v ID vydání jsem viděl pouze číslo sestavení. Nejsem si jistý, jak byste přišli s revizí čísla sestavení. Předpokládám, že pokud jste změnili některé nestavěné prostředky (ikony, skript DB atd.), Možná, ale většina projektů, na kterých jsem nedávno pracoval, má všechny tyto věci také pod kontrolou verzí, takže proces sestavení je vyzvedne, když vytvoření instalačního programu/vydání. Líbí se mi časově značená čísla sestavení, i když ne tak, jak popisuje @David (Líbí se mi major.minor.revision.HHMM). Pokud však pracuji, používáme pouze sekvenční číslo, které náš sestavovací server generuje.

1
TMN

Stejně jako jkohlhepp používáme třetí část verze k zobrazení čísla revize v Subversion a čtvrté k zobrazení čísla sestavení z našeho serveru pro kontinuální integraci (Jenkins pro nás). To nám přináší několik výhod - to, že číslo verze nastavené naším serverem CI odstraní ruční krok, který by jinak mohl být náhodně vynechán; je snadné zkontrolovat, zda vývojář neučinil drzé vydání ze svého vývojového počítače (což by mělo za následek nula); a umožňuje nám to spojit jakýkoli kus softwaru zpět s kódem, který byl vygenerován z a úlohy CI, která ji vytvořila, pouhým pohledem na číslo verze - což občas považujeme za velmi užitečné.

1
Jon Lawson

Je to, co chcete. Mám tendenci používat year.month.day.hhmm pro svou major.minor.build.revision. Pokud vyrábím více než jednu minutu, něco se děje. stačí použít jednoduchý přírůstek, nebo jsem pro ně viděl nějaké komplikované generátory. Co vy chcete, aby to bylo. To, co musí udělat, je udělat to, abyste se dostali ke zdroji použitému k vytvoření tohoto výstupu, takže cokoli vám to umožní.

0
BlackICE

Poslední dvě číslice představují celkový počet sestavení

1.01.2.1234

číslo sestavení je 2.1234, ale většina lidí použije pouze 1234, protože část 2 se často nemění.

0
lance lyons

Náš tým používá třetí číslo (revizi) jako číslo revize z úložiště Subversion. Čtvrté číslo (sestavení) používáme jako číslo sestavení z našeho serveru pro kontinuální integraci TeamCity, který ve skutečnosti sestavení vytváří. TeamCity během procesu sestavení vytvoří nový soubor AssemblyInfo s právy # v něm.

0
RationalGeek