it-swarm-eu.dev

Co obvykle představují čísla ve verzi (tj. V1.9.0.1)?

Možná je to hloupá otázka, ale vždy jsem předpokládal, že každé číslo vymezené obdobím představuje jednu součást softwaru. Pokud je to pravda, představují někdy něco jiného? Chtěl bych začít přiřazovat verze různým sestavám svého softwaru, ale nejsem si jistý, jak by měl být strukturován. Můj software má pět různých komponent.

110
BeachRunnerFred

Ve verzi 1.9.0.1:

  • 1 : Hlavní revize (nové uživatelské rozhraní, spousta nových funkcí, konceptuální změna atd.)

  • 9 : Drobná revize (možná změna vyhledávacího pole, přidání 1 funkce, kolekce oprav chyb)

  • 0 : Uvolnění opravy chyb

  • 1 : Build number (je-li použito) - to je důvod, proč vidíte framework .NET používající něco jako 2.0.4.2709

Nenajdete spoustu aplikací na čtyři úrovně, obvykle stačí 3.

159
Dillie-O

Specifikace Semantic Versioning

Toto je souhrn verze 2.0:

Vzhledem k číslu verze MAJOR.MINOR.PATCH, přírůstek:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

Další popisky pro předběžná vydání a sestavení metadat jsou k dispozici jako přípony Formátu MAJOR.MINOR.PATCH.

14
magyk

To může být velmi libovolné, a liší se od produktu k produktu. Například, s Ubuntu distribucí, 8.04 se odkazuje na 2008.April

Typicky levá většina (hlavní) čísla znamenají hlavní vydání, a více vy jdete doprava, menší změna zahrnovala.

13
rkabir
11

Čísla mohou být užitečná, jak je popsáno v jiných odpovědích, ale zvážit, jak mohou být také bezvýznamné ... Slunce, znáte Sun, Java: 1.2, 1.3, 1.4 1.5 nebo 5 pak 6. V dobrém starém Apple II čísla verze Meant Něco. V dnešní době se lidé vzdávají čísla verzí a jdou s hloupými jmény jako "Feisty fig" (nebo něco takového) a "hardy heron" a "europa" a "ganymede". Samozřejmě, že je to mnohem méně užitečné, protože se vám před přestávkou programu přestanou zobrazovat měsíce jupiteru, a protože není zřejmé, že je to novější.

8
stu

Čím více bodů, tím menší vydání. Neexistuje žádný skutečný pevný standard kromě toho - může to znamenat různé věci založené na tom, na čem se správci projektu rozhodnou.

WordPress, například, jde podél těchto řádků:

1.6 -> 2.0 -> 2.0.1 -> 2.0.2 -> 2.1 -> 2.1.1 -> 2.2 ...

1.6 až 2.0 by představovalo velké vydání - funkce, změny rozhraní, zásadní změny rozhraní API, rozbití některých 1.6 šablon a pluginů atd. 2.0 až 2.0.1 by bylo menší verzí - možná stanovení zabezpečení 2.0.2 až 2.1 by znamenalo významné uvolnění - nové funkce, obecně.

7
ceejayoz

Čísla mohou znamenat cokoliv, co chcete, ačkoliv obvykle nesouvisejí s jednotlivými komponenty, nýbrž s významnými změnami oproti údržbě ve vaší verzi.

Podívejte se na tyto zdroje:
http://www.netbeans.org/community/guidelines/process.html
http://en.wikipedia.org/wiki/Release_engineering
http://www.freebsd.org/releases/6.0R/schedule.html

Na zdraví

4
Alvaro Rodriguez

Čísla verzí obvykle nepředstavují samostatné komponenty. U některých lidí/softwaru jsou čísla poměrně libovolná. Pro ostatní představují různé části řetězce verze čísla různé věci. Některé systémy například zvyšují části čísla verze při změně formátu souboru. V 1.2.1 je tedy formát souboru kompatibilní se všemi ostatními verzemi V 1.2 (1.2.2, 1.2.3 atd.), Ale ne s V 1.3. Nakonec je to jen na vás, jaký režim chcete použít.

3
user9385

Ze souboru C # AssemblyInfo.cs můžete vidět následující:

// Version information for an Assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
/ You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
// [Assembly: AssemblyVersion("1.0.*")]
2
Thomas Jespersen

release.major.minor.revision by byl můj odhad.
Ale mezi výrobky se může značně lišit.

2
Fire Lancer

Záleží na tom, ale typická reprezentace je to major.minor.release.build.

Kde:

  • hlavní je hlavní verze vašeho softwaru, myslím .NET 3.x
  • minor je menší verze softwaru, myslím .NET x.5
  • release je vydání této verze, obvykle to opraví chyby
  • build je číslo, které označuje počet sestav, které jste provedli.

Tak například 1.9.0.1 znamená, že je to verze 1.9 vašeho softwaru, následující po 1.8 a 1.7, atd., Kde 1.7, 1.8 a 1.9 nějakým způsobem obvykle přidávají vedle bugfixů také malé množství nových funkcí. Vzhledem k tomu, že je to x.x.0.x, je to první verze 1.9 a je to první stavba této verze.

Dobré informace naleznete také v článku Wikipedie na téma .

Major.Minor.Bugs

(Nebo nějaká variace na to)

Chyby jsou obvykle opravy chyb bez nové funkce.

Menší je nějaká změna, která přidává nové funkce, ale nemění program v žádném významnějším způsobem.

Major je změna v programu, která buď přerušuje starou funkčnost, nebo je tak velká, že nějakým způsobem mění způsob, jakým by měli uživatelé program používat.

2
emeryc

Každý si vybírá, co s těmito čísly chce dělat. Byl jsem v pokušení zavolat zprávy a.b.c, protože je to stejně hloupé. To, co jsem viděl za posledních 25 let vývoje, má tendenci pracovat tímto způsobem. Řekněme, že číslo vaší verze je 1.2.3.

"1" označuje "hlavní" revizi. Obvykle se jedná o počáteční vydání, o změnu velkého prvku nebo o přepsání významných částí kódu. Jakmile je sada funkcí určena a alespoň částečně implementována, přejdete na další číslo.

"2" označuje vydání v rámci série. Často tuto pozici používáme k tomu, abychom se dostali k funkcím, které se v poslední velké verzi nedostaly. Tato pozice (2) téměř vždy označuje přidání funkce, obvykle s opravami chyb.

"3" ve většině obchodů označuje opravu/opravu opravy. Téměř nikdy, přinejmenším na komerční straně, to neznamená, že by to znamenalo významnou funkci. Pokud se funkce objeví v pozici 3, pak je to pravděpodobně proto, že někdo něco zkontroloval dříve, než jsme věděli, že musíme udělat chybu pro opravu chyb.

Mimo pozici "3"? Nemám ponětí, proč lidé dělají něco takového, prostě je to matoucí.

Pozoruhodně někteří z OSS tam hází to všechno z bláta. Například Trac verze 10 je ve skutečnosti 0.10.X.X. Myslím, že mnoho lidí ve světě OSS buď postrádá sebevědomí, nebo prostě nechtějí oznámit, že mají velké vydání.

1
mclain

Lidé ne vždy rozeznávají jemný rozdíl mezi čísly verzí 2.1, 2.0.1 nebo 2.10 - zeptejte se na technickou podporu, kolikrát s tím měli potíže. Vývojáři jsou podrobně orientovaní a obeznámeni s hierarchickými strukturami, takže je to pro nás slepý bod.

Pokud je to možné, vystavte své zákazníky jednodušším číslem verze.

1
Mark Ransom

Paradigma hlavní release.minor release.bug fix je docela běžná, myslím. 

V některých smlouvách o podpoře podniků existuje $$$ (nebo porušení smluvní odpovědnosti) spojené s tím, jak je určeno konkrétní vydání. Smlouva například může opravňovat zákazníka k určitému počtu významných verzí v určitém časovém období, nebo slibovat, že bude méně než x počet menších verzí v určitém období, nebo že tato podpora bude i nadále dostupná pro tolik uživatelů. vydání. Samozřejmě bez ohledu na to, kolik slov je uvedeno ve smlouvě, aby vysvětlili, co je hlavní verze versus menší verze, je vždy subjektivní a vždy budou existovat šedé oblasti - což povede k možnosti, že dodavatel softwaru může systém zahrát do systému. těchto smluvních ustanovení.

1
Will M

V případě knihovny vám číslo verze říká o úroveň kompatibility mezi dvěma verzemi, a tedy o tom, jak obtížné bude upgrade.

Uvolnění opravy chyb vyžaduje zachování binární, zdrojové a serializační kompatibility.

Menší verze znamenají různé věci pro různé projekty, ale obvykle nepotřebují zachovat kompatibilitu zdroje.

Hlavní čísla verzí mohou rozbít všechny tři formy.

Napsal jsem více o logice tady .

1
Craig P. Motlin

Major.minor.point.build obvykle. Major a minor jsou samy vysvětlující, bod je vydání pro několik drobných oprav chyb a sestavení je jen identifikátor sestavení.

1
Cody Brocious

Obvykle je to:

MajorVersion.MinorVersion.Revision.Build

1
Jason Punyon

Jo. Hlavní verze přidávají velké nové funkce, mohou narušit kompatibilitu nebo mají výrazně odlišné závislosti, atd.

Minorové verze také přidávají funkce, ale jsou menší, někdy odizolované verze z beta verze.

Pokud existuje třetí komponenta číslo verze, obvykle se jedná o důležité opravy chyb a opravy zabezpečení. Je-li jich více, záleží tak na produktu, že je těžké dát obecnou odpověď.

1
Paweł Hajdan

První číslo se obvykle označuje jako hlavní číslo verze. V podstatě se používá k označení významných změn mezi sestaveními (tj. Když přidáte mnoho nových funkcí, zvýšíte hlavní verzi). Komponenty s různými hlavními verzemi ze stejného produktu pravděpodobně nejsou kompatibilní.

Další číslo je menší číslo verze. To může představovat některé nové funkce, nebo množství oprav chyb nebo malých architekturních změn. Komponenty ze stejného produktu, které se liší menším číslem verze, mohou nebo nemusí fungovat společně a pravděpodobně by neměly.

Další se obvykle nazývá číslo sestavení. To může být zvýšeno denně, nebo s každým "uvolněn" stavět, nebo s každým stavět vůbec. Mohou existovat pouze malé rozdíly mezi dvěma komponenty, které se liší pouze číslem sestavení a obvykle mohou dobře spolupracovat.

Konečné číslo je obvykle číslo revize. Často je to používáno automatickým procesem sestavování, nebo když provádíte "jednorázové" sestavení pro testování.

Když se zvýšíte, vaše čísla verzí záleží na vás, ale vždy by měly být přírůstky nebo zůstat stejné. Můžete mít všechny komponenty sdíleny se stejným číslem verze nebo pouze změnou čísla verze na změněných komponentách.

0
Bob King

Číslo verze komplexního softwaru představuje celý balíček a je nezávislé na číslech verzí součástí. Verze Gizmo 3.2.5 může obsahovat verzi Foo 1.2.0 a Bar verze 9.5.4.

Při vytváření čísel verzí je použijte následovně:

  1. První číslo je hlavní vydání. Pokud provedete významné změny v uživatelském rozhraní nebo potřebujete přerušit existující rozhraní (takže uživatelé budou muset změnit kód rozhraní), měli byste přejít na novou hlavní verzi. 

  2. Druhé číslo by mělo znamenat, že byly přidány nové funkce nebo něco funguje interně. (Například databáze Oracle se může rozhodnout použít jinou strategii pro načítání dat, což zrychlí většinu věcí a některé věci pomalejší.) Stávající rozhraní by měla pokračovat v práci a uživatelské rozhraní by mělo být rozpoznatelné. 

  3. Číslování verzí je dále na osobě, která software zapisuje - Oracle používá pět (!) Skupin, tzn. verze Oracle je něco jako 10.1.3.0.5. Ze třetí skupiny dolů byste měli zavést pouze opravy chyb nebo drobné změny funkčnosti. 

0
Sten Vesterli
0
Sijin

ty, které se liší méně, by byly první dva, pro major.minor, poté by to mohlo být cokoliv od sestavení, revize, vydání, přes libovolné uživatelské algoritmy (jako v některých produktech MS)

0
BlackTigerX

Zde je to, co používáme:

  1. První číslo = Celková éra systému. Změny každých pár let a typicky představují zásadní změnu v technologii nebo v klientských funkcích nebo obojí.
  2. Druhé číslo = revize schématu databáze. Přírůstek v tomto čísle vyžaduje migraci databáze a tak je významná změna (nebo replikace systémů a změna struktury databáze vyžaduje pečlivý proces upgradu). Resetuje se na 0, pokud se změní první číslo.
  3. Třetí číslo = změna softwaru. To lze obvykle implementovat na klienta podle klienta, protože databázové schéma se nemění. Resetuje se na nulu, pokud se změní druhé číslo.
  4. Číslo verze subverze. Toto automaticky naplníme pomocí nástroje TortoiseSVN. Toto číslo se nikdy nevynuluje, ale postupně se zvyšuje. Pomocí tohoto můžeme vždy znovu vytvořit jakoukoliv verzi.

Tento systém nám slouží dobře, protože každé číslo má jasnou a důležitou funkci. Viděl jsem další týmy, které se potýkají s hlavní otázkou číslo/menší číslo (jak velká změna je velká) a já na to nevidím přínos. Pokud nepotřebujete sledovat databázové revize, stačí jít na 3 nebo 2místné číslo verze a usnadnit život!

0
Ewan Makepeace

Ve verzi v1.9.0.1: Toto je explicitní schéma verzování, které se používá, když nechcete použít název pre-release nebo sestavit jako -alpha, -beta.

1: Hlavní verze, která by mohla narušit zpětnou kompatibilitu

9: Přidání nových funkcí pro podporu aplikace spolu se zpětnou kompatibilitou s předchozí verzí.

0: Některé drobné opravy chyb

1: Číslo sestavy (číslo předběžného vydání)

ale v dnešní době nenajdete takové schéma verzování. Viz Sémantická verze [semver2.0] https://semver.org/

0
Mehul Sancheti

Každá organizace/skupina má svůj vlastní standard. Důležité je, že se budete držet toho, co si zvolíte, jinak budou vaši zákazníci zmateni. Řekl jsem, že jsem normálně použil 3 čísla:

x.yz.bbbbb. Kde: X: je hlavní verze (hlavní nové funkce) Y: je menší číslo verze (malé nové funkce, malá vylepšení bez změn uživatelského rozhraní) Z: je service pack (v podstatě stejný jako xy, ale s některými opravami chyb bbbb: je číslo sestavení a je opravdu viditelné pouze z "o boxu" s dalšími detaily pro zákaznickou podporu. bbbb je volný formát a každý výrobek může používat jeho vlastní.

0
Vasco Duarte

Kombinace major, minor, patch, build, security patch, atd.

První dva jsou hlavní a menší - zbytek bude záviset na projektu, společnosti a někdy i komunitě. V OS, jako je FreeBSD, budete mít číslo 1.9.0.1_number, které bude reprezentovat bezpečnostní patch.

0
Loren Segal

Záleží trochu na jazyce, například Delphi a C # mají různé významy.

První dvě čísla obvykle reprezentují hlavní a vedlejší verzi, tj. 1.0 pro první skutečné vydání, 1.1 pro některé důležité opravy chyb a drobné nové funkce, 2.0 pro vydání nové velké funkce.

Třetí číslo může odkazovat na “opravdu menší” verzi nebo revizi. 1.0.1 je jen velmi malá chyba, například 1.0.0. Může však také nést číslo revize ze systému řízení zdrojů, nebo stále se zvyšující číslo, které se zvyšuje s každou sestavou. Nebo datovou razítko.

Trochu podrobněji tady . "oficiálně", v .net, 4 čísla jsou "Major.Minor.Build.Revision", zatímco v Delphi jsou "Major.Minor.Release.Build". Používám "Major.Minor.ReallyMinor.SubversionRev" pro mé verzování.

0
Michael Stum

Obecně pak čísla jsou ve formátu version.major.minor.hotfix, ne jednotlivé vnitřní komponenty. Takže v1.9.0.1 by byla verze 1, hlavní verze 9 (verze v1), menší vydání (verze v1.9) 0, hot fix 1 (v1.9.0).

0
Scott Bevington