it-swarm-eu.dev

Jakou „konvenci názvů verzí“ používáte?

Jsou různé konvence pojmenování verzí vhodné pro různé projekty? Co používáte a proč?

Osobně dávám přednost sestavení čísla v šestnáctkové soustavě (např. 11BCF), toto by mělo být zvyšováno velmi pravidelně. A pak pro zákazníky jednoduché 3místné číslo verze, tj. 1.1.3.

1.2.3 (11BCF) <- Build number, should correspond with a revision in source control
^ ^ ^
| | |
| | +--- Minor bugs, spelling mistakes, etc.
| +----- Minor features, major bug fixes, etc.
+------- Major version, UX changes, file format changes, etc.
111
rjstelling

Zjistil jsem, že zřídka zcela souhlasím s Jeffem Atwoodem, ale mám sklon následovat jeho názor na .NET konvenci číslování verzí .

(Hlavní verze). (Drobná verze). (Číslo revize). (Číslo sestavy)

Častěji než ne, u osobních projektů to považuji za nadměrné. Několikrát, kdy jsem pracoval na významných projektech, jako jsou vyhledávače v C #, jsem se držel této úmluvy a byl jsem schopen ji efektivně využít jako interní sledovač.

47
Mike B

Semantická verze ( http://semver.org/ ) si zde zaslouží zmínku. Je to veřejná specifikace schématu verzování ve formě [Major].[Minor].[Patch]. Motivací pro toto schéma je komunikovat význam s číslem verze.

90
M. Dudley

Nepoužívám to, ale viděl jsem a je to zajímavá struktura:

Year.Month.Day.Build

Self vysvětlil.

33
Maniero

Snažím se použít RubyGems Rational Versioning policy , ve kterém:

  • Hlavní číslo verze se zvýší, když je přerušena binární kompatibilita
  • Po přidání nové funkce se číslo menší verze zvýší
  • Číslo sestavení se mění pro opravy chyb.
14
Ken Bloom

Zde je velmi jemnozrnný přístup k číslování verzí:

  • N.x.K, kde N a K jsou celá čísla. Příklady: 1.x.0, 5.x.1, 10.x.33. Používá se pro střední sestavení .
  • N.M.K, kde N, M a K jsou celá čísla. Příklady: 1.0.0, 5.3.1, 10.22.33. Používá se pro vydání .
  • N.x.x, kde N je celé číslo. Příklad: 1.x.x. Používá se pro podpůrné větve .
  • N.M.x, kde N a M jsou celá čísla. Příklad: 1.0.x. Používá se pro větve vydání .

Zde je obrázek pro jednoduché znázornění přístupu k číslování verzí:

Agile version numbering

PA znamená pre-alfa A znamená alfa B znamená beta AR znamená alfa-release BR znamená beta-release RC znamená kandidát na uvolnění ST znamená stabilní

Výhody takového přístupu k číslování verzí jsou následující:

  • Představuje specifika agilního životního cyklu vývoje softwaru .
  • Zohledňuje specifika struktury úložiště zdrojového kódu .
  • Je to samo vysvětlující pro ty, kteří si zvykli na vzory. Každý vzor představuje jiný artefakt. Takové vzory lze snadno analyzovat a použít pro jiné účely, jako je sledování problémů.
  • Sada vzorů verzování, která základní pro popsaný přístup k verzování lze použít pro shromažďování metrik a plánování .
  • Zaměřuje se na koncepty dospělosti a úrovně kvality . Velmi často jsou čísla verzí jako 1.0.0 přidělována bez velké nutnosti (pokud je software v hluboké alfa). Prezentovaný přístup k číslování verzí umožňuje stanovit několik úrovní zralosti. V nejjednodušším případě bude mít pouze dvě úrovně: střední sestavení (N.x.K) a vydání (N.M.K). Uvolnění znamená, že kus softwaru s plným číslem verze (N.M.K) prošel nějakým procesem řízení kvality v dodavatelské společnosti/organizaci/týmu.
  • Je to důkaz agilní povahy vývoje i testování.
  • Podporuje modulární přístup k softwarové struktuře a architektuře.

Existuje také složitější diagram představující přístup k verzování v detailech. Také byste mohli najít užitečné prezentační snímky popisující přechod k přístupu k verzování a SCMFViz aplikace ilustrující základní principy přístupu k číslování verzí. Prezentační snímky také vysvětlují, proč je důležité dodržovat stejný přístup k verzování po celou dobu životnosti softwarového projektu.

Osobně můj přístup k používání datové verze místo skutečných čísel verzí předpokládá, že vývojáři softwaru s datovanými verzemi:

  • Nevím nic o životním cyklu vývoje softwaru . Vývoj je obvykle agilní a iterativní. Přístup k číslování verzí by měl představovat iterativní povahu procesu vývoje softwaru.
  • Nezáleží na kvalitě softwaru . Kontrola a zajištění kvality jsou agilní a opakující se. Stejně jako vývoj. A číslo verze by mělo být důkazem agilní a opakující se povahy vývoje a kontroly/zajištění kvality.
  • Nestarejte se o architekturu nebo myšlenku jejich aplikace. Hlavní číslo verze (N v N.M.K) odpovídá za architektonické řešení a základní princip aplikace. Hlavní číslo verze N má být změněno v souladu se změnami v architektuře nebo změnami hlavních myšlenek a principů jeho fungování/fungování.
  • Nemají kontrolu nad jejich kódovou základnou . Pravděpodobně existuje pouze jedna větev (kmen) a používá se pro všechno. Což osobně si nemyslím, že je správné, protože to povzbuzuje kodebázu, aby se stala jednou velkou skládkou odpadu.

Tento přístup by se mohl zdát trochu kontroverzní, ale věřím, že to je nejjednodušší způsob, jak poskytnout softwaru příslušná čísla verzí.

10
altern

U každé hlavní verze, kterou vydáte, není neobvyklé mít funkční verzi, kterou nazýváte interně. Například v mé poslední práci jsme odkazovali na hlavní verzi s následující konvencí pojmenování inspirovanou Ubuntu:

[nemocný] [aliterativní jméno zvířete]

Což dalo jména jako "Limp Lamprey", "Zraněný Wombat" a "Astmatický mravenečník".

Ujistěte se, že se nejedná o skutečně skvělé jméno, které by vašim zákazníkům neuniklo.

8
Jesse C. Slicer

Generace.Verze.Revize.Build (9.99.999.9999)

Generace se zřídka mění. Pouze velký obrat na produktu: DOS -> Windows, kompletní reengineering.

Verze je určena pro velké nekompatibilní změny, nové funkce, změny některých specifických paradigmat softwaru atd.

Revize se často provádí (drobné funkce a opravy chyb).

Build je interní informace.

7
Maniero

git describe poskytuje pěkné rozšíření pro jakoukoli konvenci číslování, kterou jste si vybrali. Je to dost snadné to vložit do procesu sestavování/balení/nasazení.

Předpokládejme, že pojmenujete verze s označením A.B.C (major.minor.maintenance). git describe pro daný odevzdání nalezne nejnovější označený předchůdce odevzdání, poté se zaměřuje na počet závazků od té doby a zkrácenou SHA1 odevzdání:

1.2.3-164-g6f10c

Pokud se skutečně nacházíte v jedné z verzí, dostanete značku (1.2.3).

To má tu výhodu, že vás informujeme přesně z jakého zdroje jste postavili, aniž byste museli počítat každou jednotlivou sestavu.

6
Cascabel

Dávám přednost číslům verzí, která mají nějaký význam. Dokud můžete pomocí čísla verze sledovat chyby hlášené s konkrétní verzí ke změnám, ke kterým došlo ve zdrojovém kódu (a ve vašem systému správy aktivit), pravděpodobně používáte správnou metodu.

Používám .NET, takže jsem uvízl v systému číslování verzí .NET, ale snažím se dát sémantickému významu číslům, takže

major.minor.build.revision

  • major = (do projektu)
  • minor = (do projektu)
  • build = build number from Hudson (můžete použít TeamCity nebo TeamBuild atd.)
  • revize = Revize Subversion nebo Bazaar (v závislosti na projektu a jeho použití)

Vždy se ujistěte, že číslo verze je nějakým způsobem viditelné (u našich dávkových programů na konzoli je vytištěno na konzoli a soubor protokolu, s webovými aplikacemi obvykle na horním panelu nabídek v horní části).

Pokud klienti hlásí problémy, můžeme pomocí čísla verze sledovat, zda používají nejnovější verzi a kolik problémů jsme měli s konkrétními verzemi.

Je to všechno o sledovatelnosti!

2
Jeffrey Cameron

Major.Minor.Public (build) [alfa/beta/trial], například „4.08c (1290)“

  • Hlavní je hlavní číslo verze (1, 2, 3 ...)
  • Menší je dvouciferná menší verze (01, 02, 03 ...). Desítky se obvykle zvyšují, když je přidána významná nová funkce, ty pouze pro opravy chyb.
  • Veřejnost je veřejné vydání sestavení (a, b, c, d, e), které se často liší od menší verze, pokud menší verze není nikdy vydána jako veřejná aktualizace
  • build, což je skutečné číslo buildu, o kterém kompilátor sleduje.
  • s TRIAL, ALPHA, BETA X nebo RC X připojenými pro tyto zvláštní případy.
2
GrandmasterB

Používáme Major.Minor.Build # .YYMMDD [přípona], protože obvykle vyrábíme pouze jednu produkci v kterýkoli konkrétní den (ale příponu ab/c/d použijte, pokud existuje více než jeden) a YYMMDD dává uživatelům/zákazníkům/správě údaj o věku sestavení, kde 6.3.1389 nikoli.

Hlavní čísla se zvyšují s významnými vlastnostmi produktu (placené).

Menší počet se zvyšuje s opravami/vylepšeními (bezplatná aktualizace).

Stavět vždy zvyšuje; ne všichni staví loď, takže to není lineární postup.

1
JBRWilkinson
 1.0.0 
 | 
 1.0.1 
 
 (Veřejná 1.0) 1.0.2 ----- 
 |\
 2.0.0 1.1.0 
 | | 
 2.0.1 1.1.1 (veřejné 1.1) 
 
 (Veřejné 2.0) 2.0.2 ----- 
 |\
 3.0.0 2.1.0 
 | 
 2.1.1 (veřejná 2.1) 
 | 
 2.2.0 
 | 
 2.2.1 

X.Y.Z Je číslo naší interní verze. X.Y Je číslo veřejné verze, které má pro naše klienty význam. Když se verze X.Y.Z Stane veřejnou, nikdy nebude existovat verze X.Y.(Z+1): veřejná verze je vždy poslední ze série.

X se zvyšuje, když je vydána hlavní verze.

Y se používá pro větve údržby těchto hlavních verzí, pouze pro opravy chyb.

Z se používá interně a nemá žádný pevný význam. Až do teď vytvářím novou verzi Z, když si myslím, že aplikace má sadu funkcí, které jsou zajímavé pro ukázání vývojářům a je relativně stabilní. Tímto způsobem mohu ukázat ukázku „poslední známé dobré verze“ aplikace, když ji někdo požádá. V blízké budoucnosti plánuji v našem bugtrackeru používat pro pojmenování „cíle“ funkcí verzi s číslem Z.

Jako vedlejší poznámku používáme maven (s příkazem release) ke zvýšení čísla verze. Jsou tedy také verze X.Y.Z-SNAPSHOT (Což označuje jakoukoli verzi mezi X.Y.(Z-1) a X.Y.Z).

0
barjak