Mi pontosan a MAJOR.MINOR.BUILDNUMBER.REVISION

Még soha nem láttam ilyen formában kiírva. Ahol dolgozom, a MAJOR.MINOR.REVISION.BUILDNUMBER formátumot használjuk, ahol:

• A MAJOR egy fő kiadás (általában sok új funkció vagy változás a felhasználói felületen vagy alapul szolgáló operációs rendszer)
• A MINOR egy kisebb kiadás (talán néhány új szolgáltatás) egy korábbi nagyobb kiadáshoz
• A REVISION általában egy korábbi kisebb kiadás javítása (nincs új funkció)
• A BUILDNUMBER számot növeljük a verzió minden egyes legújabb összeállításakor.

Például kiadhat egy verziót a minőségbiztosításnak (minőségellenőrzés), és visszatérnek egy olyan kérdéshez, amely változtatást igényel. A hibát kijavítanák, és ugyanazzal a REVISION számmal, de növekvő BUILDNUMBER számmal adnák vissza a minőségbiztosításhoz.

Megjegyzések

• +1: Ez ‘ s nagyjából úgy, ahogy én ‘ láttam mindenhol másutt is. ‘ láttam és tetszett, hogy egyes vállalatok csak a DateTime bélyegzőt használják a BUILDNUMBER-hez.
• +1: A ” MAJOR.MINOR.REVISION.BUILDNUMBER ” forma érthető és értelmes. Láttam a BUILDNUMBER.REVISION űrlapot az MSDN webhelyén (a kérdéses link frissült), és ez teljesen megzavart.
• Páratlan. Azt várnám, hogy a legutóbbi felülvizsgálatnak a legérzékenyebbé válna – ‘ az a szám, amely (valószínűleg) a legjobban megváltozik.
• @Izkata, valójában a build a szám változik a legjobban, legalábbis az, ahogyan azt a mostani fő szerződésemnél használom, amely szigorú verzióellenőrzést alkalmaz, mert orvosi eszközöket gyártunk. A frissített verzió azt jelzi, hogy a korábbi szoftver javításra került, amelyet a QA (Quality Assurance) tesztelnie kell. Ez egy teljesen külön részleg, amely három napig átfogó teszteket végez (az FDA irányelveinek megfelelően). Ha bármilyen problémát találnak, akkor további kódváltásokra lehet szükség, amelyek új összeépítést igényelnek (újrafordítás és linkelés), majd újratesztelést igényelnek, de a verzió száma nem változik.
• @tcrosley azt hiszem, ‘ sa nem egyértelmű terminológia. Gondolkodtam a verziókezelés felülvizsgálatain.

Az egész zavar a különböző szemantika , amelyeket az MS használ a “Build szám” és különösen a “Revision” számára. A kifejezések csak különböző dolgokat jelentenek.

A legtöbb ember (magamat is beleértve) szemantikus verziószámozási sémát használ , ahol csak magasabb BUILD számot kap. amikor bármilyen okból új építményt kell készítenie. Számunkra a gyorsjavítás csak egy újabb kódváltozásnak számít, és a BUILD rész automatikusan növekszik minden CI-futtatással. Az azonos MAJ.MIN.REV modulokat felcserélhetőnek tekintik, és a BUILD megmondja, melyik a legfrissebb.

A növekvő REVISION azonban egy új, állandó kiadású ágat jelez, ezért helyezzük a BUILD elé.Ennek a megközelítésnek az a hátránya, hogy a következő eseménysorozatot kaphatjuk meg:

• a 4711 számú elkötelezettség: Alice hozzáadta az A funkciót
• A CI 1.2.3.100 buildet állít elő
• 4712-es elkötelezettség: Bob módosította a B funkciót
• a 4713-as számú elkötelezettség: Alice A fix szolgáltatás (a “gyorsjavítás”)
• A CI 1.2.3.101-es buildet állít elő

Amint láthatja, a gyorsjavítás nem az egyetlen változás, amelyet a következő tartalmaz build, Bob módosításai is ennek az építkezésnek a részévé válnak. Ha stabilizálni szeretné az aktuális ágat, akkor gondjai lehetnek, mivel soha nem lehet biztos abban, hogy Bob csak egy csomó hibát adott-e be.

Az MS mindkét kifejezést eltérően használja. A BUILD szám nem növekszik automatikusan, ehelyett egyfajta kiadási ágnak tekinthető, amely befagyasztja a kód egy adott verziójához használt kódot. A REVISION további “forró” változásokat jelez az adott BUILD ágra vonatkozóan. A sorrend tehát a következő lenne:

• a 4711-es szám elkötelezése: Alice az A funkciót hozzáadta a törzshöz / mesterhez
• Carl létrehoz egy építési ágat 1.2.100
• A CI 1.2.100.0 buildet készít.
• 4712-es kiosztási szám: Bob módosította a B funkciót a csomagtartóban / főben a 1.2.100 ágban
• A CI 1.2.100.1 buildet készít

A REVISION kifejezés utalhat

• a termékre átdolgozás (a legtöbb ember így használja)
• egy adott napi összeállítás felülvizsgálata (ez az, amit az MS csinál)

A legfontosabb különbség a két folyamat között az, hogy szeretné-e alkalmazni a gyorsjavításokat a CI buildjeire, és így, a folyamat mely pontján készül el az ág. Ez a szempont akkor válik fontossá, amikor azt szeretné, hogy az összes teszt sikeres legyen, és bármikor kiválaszthasson egy adott összeállítást, és pontosan ezt a verziót népszerűsítse a termék következő hivatalos kiadásakor.

Esetünkben a CI eszköz létrehoz egy adattár címkét, így szükség esetén mindig készen állunk a szükséges információk használatra. Az SVN használatával még egyszerűbbé válik, mert a címkéket és az ágakat pontosan ugyanúgy hajtják végre – a címke nem más, mint egy ág, amely a /tags alatt található.

Lásd szintén

A GYIK részben a TFS elágazási stratégiánál :

Melyik ágban kell javítanom a P1 (gyorsjavítás) jegyet?

• A P1-et abban az ágban kell rögzíteni, amely a legközelebb van a Production futtatott kódbázishoz. Ebben az esetben a P1-et a Prod ágban kell rögzíteni. A javítás bármely más ágban történő alkalmazásával és a gyártásbeli változások bevezetésével fennáll annak a veszélye, hogy félkész vagy teszteletlen kódot bocsát ki a következő iterációkból.

• Most vitatkozhat, hogy ez-e Biztonságos, ha közvetlenül a Prod ág ellen dolgozunk, gondoljuk át, hogy az azonnali figyelmet igénylő P1 nem lehet alapvető probléma a rendszerben. Ha ez alapvető probléma, akkor hozzá kell adni a Product Backloghoz, mivel további elemzést és megbeszélést igényelhet a vásárlóval.

További jó olvasnivaló a TFS elágazási útmutató

Megjegyzések

• Ez egy remek válasz! +1

A Microsoft az MSDN dokumentációjában leírja a .NET verziószám egyes komponenseinek célját. az Version osztályhoz. Itt van a releváns rész:

major.minor [.build [.revision]]

Az összetevőket egyezmény szerint használják következik:

Major: Azonos nevű, de a különféle főbb verziók nem cserélhetők fel. A magasabb verziószám egy termék jelentős átírását jelezheti, ahol a visszamenőleges kompatibilitás nem feltételezhető.

Kisebb: Ha két szerelvény neve és fő verziószáma megegyezik, de a kisebb verziószáma eltér, ez jelentős javulást jelez a visszafelé kompatibilitás szándékával. Ez a magasabb kisebb verziószám egy termék pontszerű kiadását vagy a termék teljesen visszafelé kompatibilis új verzióját jelentheti.

Build: A buildszám különbsége ugyanazon forrás újrafordítását jelenti. Különböző gyártási számok használhatók, ha a processzor, a platform vagy a fordító megváltozik.

Revízió: Azonos nevű, fő és kisebb verziószámú összeállítások, de a különböző verziók teljesen felcserélhetők. Nagyobb verziószám használható egy olyan verzióban, amely javítja a biztonsági lyukat egy korábban kiadott szerelvényben.

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

Megjegyzések

• Zavarba hoz, hogy miért nem ismeri senki ezt a szabványt, minden itteni válasz azt állítja, hogy az építkezés a végén megy, és nem ‘ t megérteni, hogy a revízió nagyon egyszerű; gyorsjavítást jelent. Felszabadít egy buildet, majd további buildeket hoz létre, de amikor vissza kell térnie és javítania kell a kiadást, frissítenie kell a verziót, hogy megjelenjen az adott kiadás, amelyet egy új kiadás módosított
• +1 olyan válasz, amelynek megalapozott építési száma van. Pusztán a szám növelése meglehetősen haszontalan, ha a verzió változatlan marad (hacsak nincs őrült felépítési rendszere, amely időfüggő). A build szám használata annak jelzésére, hogy mely fordító, platformok stb. hasznos .
• Build úgy tűnik, hogy ez egy fontos pont, amelyet elmulasztanak. Ha ‘ sa megváltoztatja a kódot (ez nem igényel ‘ t teljesen új Major / Minor növekedést igényel), akkor a Revision -et is meg kell változtatni.
• @PeterX Mint a build-specifikus változások esetén az újbóli célzásnál?
• ” Az összeállítási szám különbsége ugyanazon forrás újrafordítását jelenti. ” ellentmondani látszik a dokumentációnak. Miután elvégezte a felülvizsgálatot, az már nem ugyanaz a forrás. A BUILD előtt a REVISION előtt csak akkor van értelme, ha a revízió egy ” processzort, platformot vagy fordító ” változatot jelent. Tehát úgy gondolom, hogy a legtöbben REVISION bumpnak tekinthetőnek KISEBB bugnak kell lennie, ha ezeket a leírásokat használja. Bár a dokumentumok megemlítik a REVISION használatát a gyorsjavításokhoz, de az Id feltételezi, hogy a gyorsjavítások minden buildre vonatkoznak, ezért KISEBB hibának kell lenniük. Csak logikus következetességre vágyom !!

Legalább pár különböző dolog van, amit tudnék képzelje el a buildszám hivatkozását:

1. Forrásvezérlő verzió, amelyet kiadtak. Például, ha volt egy kiadás a # 12345 verzióról, akkor ezt nyomon lehet követni azzal, hogy ez az építési szám, és ha javításra kerül, akkor a verziók felemelkedhetnek, mivel nem olyan új funkció, amely növelné a nagyobb vagy a kisebb verziókat és emlékeztetni kell a build számára, ha valaki újra akarja futtatni az buildet.

2. Folyamatos integrációs kiszolgáló azonosító. Ebben az esetben a CI szerver megszámolhatja az összes futtatott buildet és így a build összeállítása az, amit egy sikeres összeállítás kap, és a felülvizsgálati részre nincs szükség ebben a forgatókönyvben.

Lehet, hogy vannak olyanok, akiket nem ismerek, de ezek azok a nagyok, amelyeket ismerek, amikor a kódalapú számokról van szó.

Megjegyzések

• +1 az 1. számra. Szeretem használni a forrásvezérlés # verziója, mert így sokkal könnyebb megkeresni az adott verzióval jelentett hibákat a forrásellenőrzésben.
• @MasonWheeler: remekül működik, ha SVN-en vagy. De amikor a dcv-khez érsz földet mókus lesz y. Ez egy dolog, amit legjobban hiányolok az svn I ‘ ll hozzáadásáról.

A buildszám általában minden egyes buildnél növekszik, így egyedi.

Az egyszerűség kedvéért egyesek visszaállítják a buildszámot, amikor a MAJOR vagy MINOR számok összeütköznek.

A legtöbb folyamatos integrációs motor lehetővé teszi az automatikusan generált egyedi buildszámokat.

A verzió használható a épít. Mondjuk, hogy 2 csapat dolgozik egy terméken.

Az 1. csapat a fő fejlesztőcsapat, és éjszakai építést készít a következő 1.0.X.0 verziósémával, ahol az X növekszik. Most az 1.0.50.0 verziónál tartanak. A 2. csapat időről időre épít. Mondjuk, hogy átveszik a múlt heti verziót, amely 1.0.43.0, és elkezdik használni. Az 1. csapat 1.0.51.0 szintre lép, amikor a 2. csapat hibát talál az 1.0.43.0 verzióban.

Most az 1. csapat vegye be ezt a buildet (43), javítsa ki a problémát, és adja meg a 2. csapat számára az 1.0.43.1 verziót. A javítás a fő buildben is terjeszthető lehet, így a változás az 1.0.52.0 verzióban jelenik meg.

Remélem ez egyértelmű és hasznos.

* A revízió akkor hasznos, ha nem mindenki használja a projektet, és ugyanazt a buildet használja, és javítania kell az adott buildeket.

Hadd mondjam el, hogyan látom és használom ….

ProgramName verzió major.minor.build.revision

szak: Számomra a jelenlegi projekt, amin dolgozom. A szám nem változik, amíg nem kezdek el egy új projektet ugyanazzal a programnévvel. Ez azt jelenti, hogy szó szerint új nemű programot fogok írni (példa: hozzáférés v1 – hozzáférés v-2 – hozzáférés v-3 * ugyanaz a program, de teljesen átírva).

minor: Ez azt jelenti, hogy hirdetés vagyok a jelenlegi publikált projekt funkcionalitását.Például talán hozzáadtam a nyugta kinyomtatásának lehetőségét vagy a képek importálásának lehetőségét. Alapvetően további funkciókat szeretnék most hozzáadni, és nem várom a következő nagy kiadást.

build: Ezt a közzétett major.minor verzió nagyon apró változásainak jelzésére használom. Ez változhat az elrendezésben, a színvilágban stb.

revízió: Ezt használom hibajavítás jelzésére a jelenlegi közzétett major.minor.build fájlban – Vannak olyan esetek, amikor nem haladok a projekt és egy hiba merül fel. Ezt a hibát ki kell javítani és közzé kell tenni. Ez csak azt jelenti, hogy a már publikáltakat kijavítom a megfelelő működésre. Ezt akkor is használnám, ha új felépítésen, új kiegészítésen dolgozom, vagy új nagyobb verziót kezdenék. A közzétett verziót nyilvánvalóan be kell javítani, amíg a következő nagyobb, kisebb vagy épített kiadásra várunk.

Így ilyen módon egy kész vagy elakadt projekt még javítható és használhatóvá tehető a következő kiadás megjelenéséig. közzétett.

Remélem, hogy ez valakinek jobban megérti, hogy az ilyen típusú verziók hogyan működnek (vagy hogyan kell működniük). Számomra ez az egyetlen definíció és gyakorlat, amely bármilyen típusú valódi értelmet nyújt az ilyen típusú verzió használatakor.

Csak egy build-számot láttam a kiadásazonosító utolsó számaként. Nem vagyok biztos benne, hogyan állítottál elő egy verziószámot. Feltételezem, ha megváltoztatnád a nem épített erőforrások egy részét ( ikonok, DB szkript stb.), de talán, de a legtöbb projekten, amelyen nemrégiben dolgoztam, mindezek a dolgok verzióellenőrzés alatt állnak, így a build folyamat felveszi őket a telepítő / kiadás készítésekor. Szeretem az időbélyeggel ellátott építési számokat, bár nem egészen úgy, ahogy @David leírja (szeretem a major.minor.revision.HHMM-et). Azonban ahol dolgozom, csak egy sorozatszámot használunk, amelyet a szerverünk generál.

Amit akarsz hogy legyen. Én inkább a year.month.day.hhmm-t használom a major.minor.build.revision-ért. Ha percenként egynél többet produkálok, akkor valami nem stimmel. csak egy egyszerű növekményt használhat, vagy láttam néhány bonyolult generátort számukra. Mit akarsz te tőlük. Amit meg kell tenniük, hogy elkészítsék, hogy eljussanak a megszokott forráshoz hozza létre azt a kimenetet, így bármi lehetővé teszi ezt.

Csapatunk a harmadik számot (revíziót) használja revíziószám a Subversion repository-ból. A negyedik számot (build) a TeamCity folyamatos integrációs szerverünk buildszámaként használjuk, amely ténylegesen létrehozza az építést. A TeamCity létrehoz egy új AssemblyInfo fájlt, amelyben a megfelelő #-ek vannak a build során.

A jkohlhepphez hasonlóan a verzió harmadik részét is használjuk a verziószám megjelenítésére az SubVersionban, a negyedik pedig a buildszám a folyamatos integrációs szerverünkről (nekünk Jenkins). Ez számos előnnyel jár – ha a CI-kiszolgálónk által beállított verziószám eltávolít egy manuális lépést, amely egyébként véletlenül történhet nem fogadott; könnyű ellenőrizni, hogy egy fejlesztő nem tett-e pimasz kiadást a fejlesztői PC-jéről (ami azt eredményezné, hogy ezek a számok nullaak lennének); és ez lehetővé teszi számunkra, hogy bármilyen szoftvert visszacsatoljunk mind a kódhoz, amelyet generált , mind pedig az azt építő CI jobhoz, csupán a verziószám megnézésével – amelyet időnként nagyon hasznosnak találunk.

Az utolsó két számjegy a teljes buildszám

1.01.2.1234

a gyártási szám 2.1234, azonban a legtöbb ember csak az 1234-et fogja használni, mivel a 2 rész nem változik gyakran.

Megjegyzések

• Az operációs rendszer azt kérdezi, hogy mi az építkezés száma, nem pedig az, hogy melyik verzió a verzióazonosítóban szerepel.