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

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 v uživatelském rozhraní nebo podkladový OS)
• MINOR je vedlejší vydání (možná některé nové funkce) předchozího hlavního vydání
• REVISION je obvykle oprava předchozího vedlejšího vydání (žádná nová funkce)
• BUILDNUMBER se zvyšuje pro každé nejnovější sestavení revize.

Například revize může být vydána 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 REVISE, ale s navýšeným BUILDNUMBER.

Komentáře

• +1: To ‚ s do značné míry tak, jak jsem to ‚ viděl všude jinde. Viděl jsem ‚ a líbilo se mi, jak některé společnosti používají pro datum BUILDNUMBER razítko DateTime.
• +1: “ MAJOR.MINOR.REVISION.BUILDNUMBER “ forma je srozumitelná a dává smysl. Viděl jsem formulář BUILDNUMBER.REVISION na webu MSDN (odkaz aktualizován v otázce) a úplně mě to zmátlo.
• Zvláštní. Očekával bych, že poslední revize bude mít největší smysl – je to ‚ číslo, které se (pravděpodobně) nejvíce změní.
• @Izkata, vlastně sestavení číslo se mění nejvíce, přinejmenším způsob, jakým jej nyní používáme u mé hlavní smlouvy, který používá přísnou kontrolu verzí, protože vyrábíme zdravotnické prostředky. Aktualizovaná revize naznačuje, že došlo k opravě předchozího softwaru, který je třeba otestovat QA (Quality Assurance). Toto je zcela samostatné oddělení, které provádí rozsáhlé testování po dobu tří dnů (podle pokynů FDA). Pokud zjistí nějaké problémy, může být nutné provést další změny kódu vyžadující nové sestavení (překompilovat a propojit) a poté znovu otestovat, ale číslo revize zůstane stejné.
• @tcrosley Myslím, že ‚ případ nejasné terminologie. Myslel jsem na revize v řízení verzí.

Celý zmatek pramení z odlišná sémantika , kterou MS používá pro „číslo sestavení“, zejména pro „revizi“. Tyto výrazy znamenají jen různé věci.

Většina lidí (včetně mě) používá schéma sémantického číslování verzí , kde získáte vyšší číslo BUILD kdykoli budete muset z jakéhokoli důvodu vytvořit novou sestavu. Pro nás je oprava hotfix považována pouze za další změnu kódu a BUILD část 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ší.

Přírůstková 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í posloupnost událostí:

• potvrzení číslo 4711: Funkce přidaná Alice A
• CI vytváří sestavení 1.2.3.100
• potvrzení číslo 4712: Bob upravená funkce B
• potvrzení číslo 4713: Alice opravená funkce A („oprava hotfix“)
• CI vytvoří sestavení 1.2.3.101

Jak vidíte, oprava hotfix není jedinou změnou obsaženou v následující build, také Bobova modifikace se stane součástí tohoto buildu. Pokud chcete stabilizovat aktuální 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 výrazy odlišně. BUILD číslo není automaticky zvyšováno, místo toho může být považováno za druh větve vydání, aby zmrazil kód použitý pro konkrétní verzi kódu. REVIZE označuje další „horké“ změny aplikované na tuto větev BUILD. Sekvence by tedy byla následující:

• potvrzení číslo 4711: Alice přidala funkci A do kufru / master
• Carl vytvoří větev sestavení 1.2.100
• CI produkuje sestavení 1.2.100.0
• potvrzení číslo 4712: Bob upravený prvek B v kufru / hlavní
• potvrzení číslo 4713: Alice opravený prvek A ve 1.2.100 větvi
• CI produkuje build 1.2.100.1

Termín REVISION může odkazovat na

• a produkt revize (tak ji většina lidí používá)
• revize konkrétního každodenního sestavení (to je to, co dělá MS)

Klíčovým rozdílem mezi těmito dvěma procesy je, zda chcete možnost použít opravy hotfix na sestavení CI, a tedy, v kterém bodě procesu je vytvořena větev. Tento aspekt se stává důležitým, když chcete mít možnost vybrat si konkrétní sestavení kdykoli po úspěšném provedení všech testů 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 máme v případě potřeby vždy připraveny potřebné informace k použití. S 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 jiného než větev umístěná pod /tags.

Viz také

V sekci Časté dotazy na stránce Strategie větvení TFS :

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

• P1 by měl být opraven ve větvi, která je nejblíže základně kódu spuštěné v produkci. V tomto případě by měla být P1 fixována ve větvi Prod. Použitím opravy v jakékoli jiné větvi a zavedením změn do výroby riskujete uvolnění polotovaru nebo nevyzkoušeného kódu z následujících iterací.

• Nyní můžete argumentovat, pokud je bezpečně pracovat přímo proti pobočce Prod, přemýšlejte znovu, P1, který vyžaduje okamžitou pozornost, by neměl být zásadní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 nevyřízeného produktu, protože může vyžadovat další analýzu a diskusi se zákazníkem.

Dalším dobrým přečtením je Průvodce větvením TFS

Komentáře

• To je skvělá odpověď! +1

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

major.minor [.build [.revision]]

Komponenty se konvenčně používají jako takto:

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

Vedlejší: Pokud jsou název a hlavní číslo verze ve dvou sestavách stejné, ale vedlejší číslo verze je jiné, to naznačuje významné vylepšení se záměrem zpětné kompatibility. Toto vyšší číslo vedlejší verze může znamenat bodové vydání produktu nebo plně zpětně kompatibilní novou verzi produktu.

Sestavení: Rozdíl v počtu sestavení představuje rekompilaci 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ím a vedlejším číslem verze, ale různé revize mají být plně zaměnitelné. V sestavení, které opravuje bezpečnostní díru v dříve vydané sestavě, může být použito vyšší číslo revize.

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

Komentáře

• To mě překvapuje, proč nikdo tento standard nezná, každá odpověď zde tvrdí, že build jde na konec a ne ‚ t pochopit revize je velmi jednoduchá; to znamená opravu hotfix. Vydáte sestavení a poté vytvoříte další sestavení, ale když se budete muset vrátit a opravit toto vydání, aktualizujete revizi, aby se ukázalo, že konkrétní sestavení, které bylo vydáno, bylo změněno pro nové vydání
• +1 pro odpověď, která má oprávněné číslo sestavení. Pouhé zvyšování počtu je spíše k ničemu, pokud revize zůstane stejná (pokud nemáte šílený systém sestavení, který je závislý na čase). Použití čísla sestavení k signalizaci toho, co je kompilátor, platforma atd. užitečné .
• Build jako recompilation of the same source se zdá být důležitým bodem, který chybí. Pokud to ‚ sa změní kód (to nevyžaduje ‚ t zcela nové větší / menší zvýšení), pak Revision musí být také změněno.
• @PeterX Stejně jako v případě změn specifických pro sestavení při opětovném cílení?
• “ Rozdíl v počtu sestavení představuje rekompilaci stejného zdroje “ se zdá být v rozporu s dokumentací. Jakmile provedete revizi, již nebude stejný zdroj. Mít BUILD před REVIZÍ má smysl, pouze pokud je revize specifická pro sestavení představující “ změnu procesoru, platformy nebo kompilátoru „. Takže myslím, že to, co většina vidí jako REVISION bump, by mělo být při použití těchto popisů opravdu MINOR Bump. Ačkoli dokumenty zmiňují použití REVISION pro opravy hotfix, ale předpokládám, že opravy hotfix by se vztahovaly na všechna sestavení, a měly by proto být MINOR. Chci jen logickou konzistenci !!

Existuje alespoň několik různých věcí, které bych mohl představte si odkaz na číslo sestavení:

1. Verze řízení zdroje, která byla vydána. Například pokud došlo k vydání revize # 12345, lze to sledovat tak, že se jedná o číslo sestavení, a pokud je opravené, může se revize zvyšovat, protože nejde o nové funkce, které by zvýšily hlavní nebo vedlejší verze a číslo sestavení je třeba si zapamatovat pro případ, že by někdo chtěl toto sestavení znovu spustit.

2. Identifikátor serveru pro nepřetržitou integraci. V takovém případě může server CI očíslovat každé sestavení, které spustí a tedy číslo sestavení je to, co získá úspěšné sestavení a revizní část není v tomto scénáři nutná.

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

Komentáře

• +1 pro # 1. Rád používám revize # kontroly zdroje, protože díky ní je mnohem jednodušší vyhledávat chyby nahlášené proti dané verzi v ovládání zdroje.
• @MasonWheeler: funguje skvěle, pokud jste na SVN. Ale když se dostanete na DCV, přistupte dostane veverku y. To by byla jedna věc, která mi nejvíc chybí na svn. „answer“>

  Číslo sestavení se obvykle zvyšuje u každého sestavení, takže je jedinečné.

  Kvůli zjednodušení někteří resetují číslo sestavení vždy, když dojde k narušení hlavních nebo menších čísel.

  Většina modulů pro kontinuální integraci umožňuje automaticky generovaná jedinečná čísla sestavení.

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

Team 1 je hlavní vývojový tým a produkuje noční sestavení s následujícím schématem verze 1.0.X.0, kde se zvyšuje X. Nyní jsou na sestavení 1.0.50.0 Team 2 čas od času vezme sestavení. Řekněme, že vezmou verzi z minulého týdne, která je 1.0.43.0, a začnou ji používat. Tým 1 postoupí na 1.0.51.0, když tým 2 najde problém v 1.0.43.0.

Nyní tým 1 vezměte tuto sestavu (43), opravte problém a poskytněte týmu 2 sestavení 1.0.43.1. Oprava může být šířena také v hlavní sestavě, takže změna se objeví v 1.0.52.0.

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

* Revize je užitečná, když ne každý, kdo se podílí na projektu, používá stejné sestavení a potřebujete opravit konkrétní sestavení.

Dovolte mi, abych řekl, jak to vidím, a používám to ….

Verze programu název major.minor.build.revision

major: Pro mě je aktuální projekt, na kterém pracuji. Číslo se nezmění, dokud nespustím nový projekt se stejným názvem programu. To znamená, že doslova budu psát nový program stejného pohlaví (příklad: access v1 – access v-2 – přístup v-3 * stejný program, ale zcela přepsán).

minor: To znamená, že jsem reklama funkčnost aktuálního publikovaného projektu.Například jsem možná přidal možnost vytisknout účtenku nebo přidal možnost importovat obrázky. V zásadě další funkce, které chci přidat hned a nečekat, až to udělá další hlavní vydání.

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

revize: Tímto označuji opravu chyby v aktuálně publikovaném major.minor.build – Existují příležitosti, kdy nepostupuji aktuální projekt a objeví se chyba. Tuto chybu je třeba opravit a publikovat. Znamená to jen, že opravuji to, co jsem již publikoval, aby fungovalo správně. Také bych to použil, pokud pracuji na nové sestavě, novém přírůstku nebo zahájím novou hlavní verzi. Publikovanou verzi je zjevně třeba opravit, zatímco čekáme na další hlavní, vedlejší nebo sestavené vydání.

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

Doufám, že to někomu pomůže lépe pochopit, jak by tento typ verzí fungoval (nebo by 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.

„Pouze jsem kdy viděl číslo sestavení jako poslední číslo v ID vydání. Nejsem si jistý, jak přijdeš s revizí čísla sestavení. Předpokládám, že pokud bys změnil některé nepostavené zdroje ( 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 při vytváření instalačního programu / vydání. Mám rád časově značená čísla sestavení, i když ne tak, jak popisuje @David (mám rád major.minor.revision.HHMM). Kde však pracuji, používáme pouze pořadové číslo, které generuje náš server sestavení.

Je to, co chcete to bude. Mám sklon používat year.month.day.hhmm pro mé major.minor.build.revision. Pokud vyrábím více než jednu minutu, něco není v pořádku. stačí použít jednoduchý přírůstek, nebo jsem pro ně viděl několik komplikovaných generátorů. Co vy chcete, aby to bylo. Co musí udělat, je udělat to, abyste se dostali ke zdroji, na který jste zvyklí vytvořte tento výstup, ať vám to umožní cokoli.

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 nepřetržitou integraci TeamCity, který skutečně vytváří sestavení. TeamCity během procesu sestavování vytvoří nový soubor AssemblyInfo se správnými #s v něm.

Stejně jako jkohlhepp používáme třetí část verze k zobrazení čísla revize v SubVersion a čtvrtá k zobrazení sestavení čísla z našeho serveru pro nepřetržitou integraci (Jenkins pro nás). To nám dává 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ě minul; je snadné zkontrolovat, že vývojář neudělal drzé vydání ze svého vývojového počítače (což by vedlo k tomu, že by tato čísla byla nulová); a umožňuje nám spojit jakýkoli software zpět s kódem, který byl vygenerován z a úlohy CI, která jej vytvořila, pouhým pohledem na číslo verze – což občas považujeme za velmi užitečné.

Poslední dvě číslice jsou celkové číslo sestavení

1.01.2.1234

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

Komentáře

• OP se ptá, jaké je číslo sestavení, ne jaké je číslo sestavení v ID revize.