Vad exakt är build-numret i MAJOR.MINOR.BUILDNUMBER.REVISION

Jag har aldrig sett det skrivet ut i den formen. Där jag arbetar använder vi formuläret MAJOR.MINOR.REVISION.BUILDNUMBER, där:

• MAJOR är en viktig version (vanligtvis många nya funktioner eller ändringar av användargränssnittet eller underliggande operativsystem)
• MINOR är en mindre version (kanske några nya funktioner) på en tidigare större version
• REVISION är vanligtvis en fix för en tidigare mindre version (ingen ny funktionalitet)
• BUILDNUMBER ökas för varje senaste version av en revision.

Till exempel kan en version släppas till QA (kvalitetskontroll), och de kommer tillbaka med en fråga som kräver en förändring. Felet skulle fixas och släppas tillbaka till QA med samma REVISION-nummer, men ett inkrementerat BUILDNUMBER.

Kommentarer

• +1: Att ’ är ganska mycket som jag ’ har sett det överallt också. Jag ’ har sett och gillat hur vissa företag bara använder ett DateTime-stämpel för BUILDNUMBER.
• +1: ” MAJOR.MINOR.REVISION.BUILDNUMBER ” formen är förståelig och meningsfull. Jag såg formuläret BUILDNUMBER.REVISION på MSDN-webbplatsen (länk uppdaterad i fråga) och det förvirrade mig helt.
• Udda. Jag förväntar mig att revisionen är sist för att ge mest mening – det ’ är det nummer som (troligen) kommer att förändras mest.
• @Izkata, faktiskt byggnaden antalet ändras mest, åtminstone hur vi använder det vid mitt huvudavtal just nu som använder strikt versionskontroll eftersom vi tillverkar medicintekniska produkter. En uppdaterad version visar att det har funnits en korrigering av den tidigare programvaran, som måste testas av QA (Quality Assurance). Detta är en helt separat avdelning som gör omfattande test i tre dagar (enligt FDA-riktlinjer). Om de hittar några problem kan ytterligare kodändringar vara nödvändiga som kräver en ny version (kompilera och länka) och sedan testa om, men revisionsnumret förblir detsamma.
• @tcrosley Jag antar att det ’ ett fall av oklar terminologi. Jag tänkte på versioner av versionskontroll.

Hela förvirringen härrör från olika semantik som MS använder för ”Byggnummer” och särskilt ”Revision”. Termerna betyder bara olika saker.

De flesta människor (inklusive mig själv) använder ett semantiskt versionnummereringsschema där du bara får ett högre BYGGNUMMER närhelst du måste göra en ny byggnad av någon anledning. För oss anses en snabbkorrigering bara vara en ny kodändring, och BUILD-delen ökar automatiskt med varje CI-körning. Moduler med samma MAJ.MIN.REV anses utbytbara och BUILD berättar vilken som är den senaste.

Ökande REVISION indikerar dock en ny gren för permanent release, det är därför vi placerar den före BUILD.Nackdelen med detta tillvägagångssätt är att vi kan få följande sekvens av händelser:

• engagemang nummer 4711: Alice lade till funktion A
• CI producerar build 1.2.3.100
• engagemang nummer 4712: Bob modifierade funktion B
• engagemang nummer 4713: Alice fixade funktion A (”snabbkorrigeringen”)
• CI producerar build 1.2.3.101

Som du ser är snabbkorrigeringen inte den enda ändringen i nästa bygg, även Bobs modifiering blir en del av den byggnaden. Om du vill stabilisera den nuvarande filialen kan du stöta på problem eftersom du aldrig kan vara säker på om Bob bara har lagt till en massa buggar eller inte.

MS använder båda termerna på olika sätt. BUILD-numret ökas inte automatiskt, det kan istället betraktas som en slags filial för att frysa koden som används för en viss version av koden. REVISIONEN anger ytterligare ”heta” ändringar som tillämpas på den BUILD-filialen. Sekvensen skulle därför vara som följer:

• engagemang nummer 4711: Alice lade till funktion A till trunk / master
• Carl skapar bygggren 1.2.100
• CI producerar build 1.2.100.0
• engagemang nummer 4712: Bob modifierade funktion B i bagage / master
• engagemang nummer 4713: Alice fixade funktion A i 1.2.100 -grenen
• CI producerar build 1.2.100.1

Termen REVISION kan hänvisa till

• a produkt revision (så är det som de flesta använder den)
• en revision av en viss daglig uppbyggnad (det är vad MS gör)

Huvudskillnaden mellan de två processerna är, huruvida du vill ha möjligheten att tillämpa snabbkorrigeringar på CI-byggnader och därmed, vid vilken tidpunkt i processen filialen tillverkas. Denna aspekt blir viktig när du vill kunna välja en viss byggnad när som helst efter att alla tester lyckats och marknadsföra exakt den versionen till nästa officiella release av din produkt.

I vårt fall skapar CI-verktyget en förvarstagg, så att vi alltid har nödvändig information redo att användas vid behov. Med SVN blir det ännu enklare, eftersom taggar och grenar implementeras exakt på samma sätt – en tagg är inget annat än en gren som ligger under /tags.

Se även

Från avsnittet FAQ på TFS-förgreningsstrategi :

I vilken gren ska jag fixa P1-biljetten (snabbkorrigering)?

• P1 ska fixas i den gren som ligger närmast kodbasen som körs i produktion. I detta fall bör P1 fixas i Prod-grenen. Genom att tillämpa fixen i någon annan gren och rulla ut produktionsändringarna riskerar du att släppa halvfärdig eller otestad kod från efterföljande iterationer.

• Nu kan du diskutera om det är säkert att arbeta direkt mot Prod-filialen, tänk igen, en P1 som kräver omedelbar uppmärksamhet borde inte vara ett grundläggande problem i systemet. Om det är ett grundläggande problem bör det läggas till i produktbackloggen eftersom det kan kräva ytterligare analys och diskussion med kunden.

En annan bra läsning är TFS-förgreningsguide

Kommentarer

• Detta är ett bra svar! +1

Microsoft beskriver syftet med varje komponent i ett .NET-versionsnummer i deras MSDN-dokumentation för klassen Version. Här är den relevanta delen:

major.minor [.build [.revision]]

Komponenterna används enligt konvention som följer:

Major: Assemblies med samma namn men olika huvudversioner är inte utbytbara. Ett högre versionsnummer kan indikera en större omskrivning av en produkt där bakåtkompatibilitet inte kan antas.

Mindre: Om namnet och huvudversionnumret på två enheter är desamma, men det mindre versionnumret är annorlunda, detta indikerar betydande förbättring med avsikt att bakåtkompatibilitet. Detta högre mindre versionnummer kan indikera en punktutgåva av en produkt eller en helt bakåtkompatibel ny version av en produkt.

Bygg: En skillnad i byggnummer representerar en omkompilering av samma källa. Olika byggnummer kan användas när processorn, plattformen eller kompilatorn ändras.

Revision: Assemblies med samma namn-, huvud- och mindre versionsnummer men olika versioner är avsedda att vara helt utbytbara. Ett högre revisionsnummer kan användas i en version som fixar ett säkerhetshål i en tidigare släppt enhet.

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

Kommentarer

• Det förvirrar mig varför ingen känner till denna standard, varje svar här hävdar att build går i slutet och inte ’ t förstår att revision är väldigt enkel; det betyder snabbkorrigering. Du släpper en build och skapar sedan ytterligare builds, men när du måste gå tillbaka och fixa den versionen uppdaterar du versionen så att den specifika build som släpptes ändrades för en ny release
• +1 för ett svar som har ett motiverat byggnummer. Att bara öka antalet är ganska värdelöst om revisionen förblir densamma (såvida du inte har ett galet byggsystem som är tidsberoende). Använda build-numret för att signalera vilken kompilator, plattformar etc. som är användbart.
• Build som en recompilation of the same source verkar vara en viktig punkt som missas. Om det ’ är en kodändring (som inte ’ t kräver en helt ny Major / Minor-ökning) kommer Revision måste också ändras.
• @PeterX Som i fallet med byggspecifika förändringar vid ominriktning?
• ” En skillnad i byggnummer representerar en rekompilering av samma källa ” verkar motsäga dokumentationen. När du har gjort en revision är det inte längre samma källa. Att ha BYGGT före REVISION är meningsfullt endast om en revision är specifik för en version som representerar en ” processor, plattform eller kompilatorändring ”. Så jag antar att det som de flesta ser som en REVISION-bump verkligen borde vara en MINDRE bump när man använder dessa beskrivningar. Även om dokumenten nämner att använda REVISION för snabbkorrigeringar, men jag antar att snabbkorrigeringar skulle gälla för alla byggnader, och bör därför vara en MINDRE bump. Jag vill bara ha en logisk konsistens !!

Det finns åtminstone ett par olika saker som jag kunde föreställ dig byggnummer som refererar till:

1. Källkontrollversion som släpptes. Till exempel om det fanns en version av version # 12345, kan detta spåras genom att det är byggnumret och om det är lappat, det är där revisioner kan gå upp eftersom det inte är någon ny funktion som skulle öka de större eller mindre versionerna och build-numret måste komma ihåg om någon vill köra den build igen.

2. Kontinuerlig integrationsserveridentifierare. I det här fallet kan CI-servern numrera varje build den kör och därmed är build-numret vad en lyckad build får och revisionsdelen behövs inte i det här scenariot.

Det kan finnas andra som jag inte vet, men det här är de stora som jag känner till när det gäller siffror på kodbaser.

Kommentarer

• +1 för # 1. Jag gillar att använda revision av källkontroll #, eftersom det gör det mycket lättare att slå upp buggar som rapporterats mot den versionen i källkontroll.
• @MasonWheeler: fungerar bra om du är på SVN. Men när du kommer till DCV landar det blir ekorre y. Det här är en sak jag saknar mest om svn I ’ ll lägg till.

Revisionen kan användas för korrigeringar av bygger. Låt oss säga att två lag arbetar på en produkt.

Team 1 är det stora utvecklingsteamet och producerar nattlig byggnad med följande versionsschema 1.0.X.0, där X ökas. Nu är de på build 1.0.50.0 Team 2 tar en build då och då. Låt oss säga att de tar byggnaden från förra veckan som är 1.0.43.0 och börjar använda den. Team 1 går vidare till 1.0.51.0 när team 2 hittar ett problem i 1.0.43.0.

Nu kommer team 1 att ta den build (43), fixa problemet och ge team 2 build 1.0.43.1. Fixen kan också spridas i huvudbyggnaden, så ändringen visas i 1.0.52.0.

Hope detta är tydligt och användbart.

* Revision är användbar när inte alla som är inblandade i projektet använder samma build och du behöver korrigera specifika builds.

Låt mig bara säga hur jag ser och använder det ….

Programnamn version major.minor.build.revision

major: För mig är det nuvarande projektet jag jobbar med. Numret ändras inte förrän jag startar ett nytt projekt med samma programnamn. Det betyder att jag bokstavligen kommer att skriva ett nytt program av samma kön (exempel: access v1 – access v-2 – access v-3 * alla samma program men helt omskrivna).

minor: Detta betyder att jag är annons funktionalitet till det aktuella publicerade projektetTill exempel kanske jag lade till möjligheten att skriva ut ett kvitto eller lade till möjligheten att importera bilder. I grund och botten ytterligare funktionalitet som jag vill lägga till nu och inte vänta på nästa stora version för att göra det.

build: Detta använder jag för att indikera mycket små förändringar i den publicerade major.minor-versionen. Detta kan vara en förändring i layout, färgschema etc.

revision: Detta använder jag för att indikera en buggfix i den aktuella publicerade major.minor.build – Det finns tillfällen där jag inte fortsätter aktuellt projekt och ett fel uppstår. Detta fel måste åtgärdas och publiceras. Det betyder bara att jag fixar det jag redan publicerade för att fungera ordentligt. Jag skulle också använda detta om jag jobbar med en nybyggnad, ett nytt tillskott eller startar en ny större version. Den publicerade versionen måste uppenbarligen lappas medan vi väntar på nästa stora, mindre eller build-release.

Så på detta sätt kan ett färdigt eller fastnat projekt fortfarande fixas och göras användbart tills nästa release är publicerad.

Jag hoppas att detta ger någon en bättre förståelse för hur denna typ av versionering skulle (eller borde) fungera. För mig är det den enda definitionen och praxis som gör någon form av verklig mening när man använder denna typ av versionering.

Jag har bara någonsin sett ett byggnummer som det sista numret i släpp-ID. Jag är inte säker på hur du skulle komma med en revision av ett byggnummer. Jag antar att om du ändrade några av de icke-byggda resurserna ( ikoner, DB-skript osv.), kanske, men de flesta projekt som jag nyligen har arbetat med har också alla de sakerna under versionskontroll, så byggprocessen plockar upp dem när jag gör installationsprogrammet / release. Jag gillar tidsstämplade byggnummer, men inte riktigt som @David beskriver (jag gillar major.minor.revision.HHMM). Men där jag jobbar använder vi bara ett sekvensnummer som vår byggserver genererar.

Det är vad du vill det ska vara. Jag brukar använda år.månaddag.hhmm för mitt stora.minor.bygg.revision. Om jag producerar mer än en per minut är det fel. du kan bara använda ett enkelt steg, eller så har jag sett några detaljerade generatorer för dem. Vad du vill att det ska vara. Vad de behöver göra är att göra det så att du kommer till källan som brukade skapa den utgången, så vad som helst som gör att du kan göra det.

Vårt team använder det tredje numret (revision) som revisionsnummer från Subversion-arkivet. Vi använder det fjärde numret (build) som build-nummer från vår TeamCity kontinuerliga integrationsserver som faktiskt skapar build. TeamCity skapar en ny AssemblyInfo-fil med rätt #s i under byggprocessen. / p>

Liksom jkohlhepp använder vi den tredje delen av versionen för att visa revisionsnumret i SubVersion och den fjärde för att visa byggnummer från vår kontinuerliga integrationsserver (Jenkins för oss). Detta ger oss flera fördelar – att ha det versionsnummer som ställts in av vår CI-server tar bort ett manuellt steg som annars skulle kunna bli av misstag missade; det är lätt att kontrollera att en utvecklare inte har gjort en fräck release från sin utvecklings-PC (vilket skulle resultera i att dessa siffror skulle vara noll); och det låter oss koppla tillbaka vilken programvara som helst till både koden som den genererades från och CI-jobbet som byggde den, bara genom att titta på versionsnumret – vilket vi ibland tycker är mycket användbart.

De två sista siffrorna är det totala antalet byggnader

1.01.2.1234

byggnumret är 2.1234 men de flesta använder bara 1234 eftersom 2-delen inte ändras ofta.

Kommentarer

• OP frågar vad som är build-numret, inte vilket är build-numret i revisions-ID.