Hvad præcist er build-nummeret i MAJOR.MINOR.BUILDNUMBER.REVISION

Jeg har aldrig set det skrevet ud i den form. Hvor jeg arbejder, bruger vi formularen MAJOR.MINOR.REVISION.BUILDNUMBER, hvor:

• MAJOR er en vigtig udgivelse (normalt mange nye funktioner eller ændringer i brugergrænsefladen eller underliggende operativsystem)
• MINOR er en mindre udgivelse (måske nogle nye funktioner) på en tidligere større udgivelse
• REVISION er normalt en løsning til en tidligere mindre udgivelse (ingen ny funktionalitet)
• BUILDNUMBER øges for hver seneste version af en revision.

For eksempel frigives en revision muligvis til QA (kvalitetskontrol), og de kommer tilbage med et problem, som kræver en ændring. Fejlen ville blive rettet og frigivet tilbage til QA med det samme REVISION-nummer, men et inkrementeret BUILDNUMBER.

Kommentarer

• +1: At ‘ er stort set som jeg ‘ også har set det overalt. Jeg ‘ har set og ønsket, hvordan nogle virksomheder bare bruger et DateTime-stempel til BUILDNUMBER.
• +1: ” MAJOR.MINOR.REVISION.BUILDNUMBER ” form er forståelig og giver mening. Jeg så BUILDNUMBER.REVISION-formularen på MSDN-webstedet (link opdateret i spørgsmålet), og det forvirrede mig fuldstændigt.
• Odd. Jeg forventer, at revision er sidst for at give mest mening – det ‘ er det nummer, der (sandsynligvis) ændrer sig mest.
• @Izkata, faktisk bygningen antallet ændres mest, mindst den måde, vi bruger det på min hovedkontrakt lige nu, der bruger streng versionskontrol, fordi vi fremstiller medicinsk udstyr. En opdateret revision indikerer, at der har været en løsning på den tidligere software, som skal testes af QA (Quality Assurance). Dette er en helt separat afdeling, der udfører omfattende test i tre dage (ifølge FDA-retningslinjer). Hvis de finder nogen problemer, kan det være nødvendigt med yderligere kodeændringer, der kræver en ny build (genkompilering og link) og derefter testes igen, men revisionsnummeret forbliver det samme.
• @tcrosley Jeg tror det ‘ et tilfælde af uklar terminologi. Jeg tænkte på revisioner af versionskontrol.

Hele forvirringen stammer fra forskellig semantik som MS bruger til “Build nummer” og især “Revision”. Udtrykkene betyder bare forskellige ting.

De fleste mennesker (inklusive mig selv) bruger et semantisk version nummereringsskema , hvor du bare får et højere BUILD-nummer når du skal lave en ny build af en eller anden grund. For os betragtes et hotfix som blot endnu en kodeændring, og BUILD-delen øges automatisk med hver CI-kørsel. Moduler med samme MAJ.MIN.REV betragtes som udskiftelige, og BUILD fortæller dig, hvilken der er den nyeste.

En stigende REVISION indikerer imidlertid en ny gren for permanent frigivelse, hvorfor vi placerer den før BUILD.Ulempen ved denne tilgang er, at vi muligvis får følgende rækkefølge af begivenheder:

• commit nummer 4711: Alice tilføjede funktion A
• CI producerer build 1.2.3.100
• forpligtelsesnummer 4712: Bob ændrede funktion B
• forpligtelsesnummer 4713: Alice fikseret funktion A (“hotfix”)
• CI producerer build 1.2.3.101

Som du kan se, er hotfixet ikke den eneste ændring, der er indeholdt i den næste build, også Bobs modifikation bliver en del af denne build. Hvis du vil stabilisere den nuværende gren, kan du komme i problemer, da du aldrig kan være sikker på, om Bob bare har tilføjet en masse bugs.

MS bruger begge udtryk forskelligt. BUILD-nummeret øges ikke automatisk, i stedet kan det betragtes som en slags frigivelsesgren for at fryse den kode, der bruges til en bestemt version af koden. REVISIONEN angiver yderligere “varme” ændringer, der er anvendt på den BUILD-filial. Sekvensen ville derfor være som følger:

• commit nummer 4711: Alice tilføjede funktion A til trunk / master
• Carl opretter build-gren 1.2.100
• CI producerer build 1.2.100.0
• commit nummer 4712: Bob modificerede funktion B i bagagerum / master
• commit number 4713: Alice fixed feature A i 1.2.100 -grenen
• CI producerer build 1.2.100.1

Udtrykket REVISION kan henvise til

• a produkt revision (sådan bruger de fleste det)
• en revision af en bestemt daglig opbygning (det er hvad MS gør)

Hovedforskellen mellem de to processer er, om du vil have evnen til at anvende hotfixes til CI-builds og dermed, på hvilket tidspunkt i processen grenen fremstilles. Dette aspekt bliver vigtigt, når du når som helst vil være i stand til at vælge en bestemt build, efter at alle testene er lykkedes, og promovere nøjagtigt den version til den næste officielle udgivelse af dit produkt.

I vores tilfælde opretter CI-værktøjet et depot-tag, så vi har altid de nødvendige oplysninger klar til brug, når det er nødvendigt. Med SVN bliver det endnu enklere, fordi tags og grene implementeres nøjagtigt på samme måde – et tag er intet andet end en gren placeret under /tags.

Se også

Fra FAQ-sektionen på TFS-forgreningsstrategi :

I hvilken gren skal jeg rette P1 (hotfix) -billetten?

• P1 skal være fast i den gren, der er tættest på kodebasen, der kører i produktion. I dette tilfælde skal P1 være fast i Prod-grenen. Ved at anvende rettelsen i en hvilken som helst anden gren og udrulle produktionsændringerne risikerer du at frigive halvfærdig eller uprøvet kode fra de efterfølgende gentagelser.

• Nu kan du argumentere for, om det er sikkert at arbejde direkte mod Prod-filialen, tænk igen, en P1, der kræver øjeblikkelig opmærksomhed, bør ikke være et grundlæggende problem i systemet. Hvis det er et grundlæggende problem, skal det føjes til produktets efterslæb, da det kan kræve yderligere analyse og diskussion med kunden.

En anden god læsning er TFS-forgreningsvejledning

Kommentarer

• Dette er et godt svar! +1

Microsoft beskriver formålet med hver komponent i et .NET-versionsnummer i deres MSDN-dokumentation til Version klassen. Her er den relevante del:

major.minor [.build [.revision]]

Komponenterne bruges ved konvention som følger:

Major: Samlinger med samme navn, men forskellige hovedversioner kan ikke udskiftes. Et højere versionsnummer kan indikere en større omskrivning af et produkt, hvor bagudkompatibilitet ikke kan antages.

Mindre: Hvis navnet og hovedversionsnummeret på to samlinger er ens, men det mindre versionsnummer er forskelligt, dette indikerer betydelig forbedring med den hensigt bagudkompatibilitet. Dette højere mindre versionsnummer kan indikere en punktudgivelse af et produkt eller en fuldt bagudkompatibel ny version af et produkt.

Byg: En forskel i build-nummer repræsenterer en genkompilering af den samme kilde. Forskellige build-numre kan bruges, når processoren, platformen eller compileren ændres.

Revision: Samlinger med samme navn, større og mindre versionsnumre, men forskellige versioner er beregnet til at være fuldt udskiftelige. Et højere revisionsnummer kan bruges i en build, der løser et sikkerhedshul i en tidligere frigivet samling.

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

Kommentarer

• Det forvirrer mig, hvorfor ingen kender denne standard, hvert svar her hævder, at build går i slutningen og ikke ‘ t forstår revision er meget enkel; det betyder hotfix. Du frigiver en build og opretter derefter yderligere builds, men når du er nødt til at gå tilbage og rette den release, opdaterer du revisionen for at vise den specifikke build, der blev frigivet, blev ændret til en ny release
• +1 for et svar, der har et berettiget build-nummer. Bare at øge antallet er ret ubrugeligt, hvis revisionen forbliver den samme (medmindre du har et sindssygt build-system, der er tidsafhængigt). Brug af build-nummeret til at signalere, hvad kompilator, platforme osv. er nyttigt.
• Build som en recompilation of the same source synes at være et vigtigt punkt, der går glip af. Hvis det ‘ en kodeændring (der ikke ‘ t kræver en helt ny større / mindre stigning), så Revision skal også ændres.
• @PeterX Som i tilfælde af byggespecifikke ændringer, når du målretter igen?
• ” En forskel i buildnummer repræsenterer en rekompilering af den samme kilde ” synes at være i modstrid med dokumentationen. Når du foretager en revision, er det ikke længere den samme kilde. At have BYGGET før REVISION giver kun mening, hvis en revision er specifik for en build, der repræsenterer en ” processor-, platform- eller compilerændring “. Så jeg gætter på, at hvad de fleste ser som en REVISION-bump, virkelig burde være en MINDRE bump, når man bruger disse beskrivelser. Selvom dokumenterne nævner at bruge REVISION til hotfixs, men Id antager, at hotfixs vil gælde for alle builds, og bør derfor være en MINDRE bump. Jeg vil bare have en vis logisk konsistens !!

Der er i det mindste et par forskellige ting, jeg kunne forestil dig det build-nummer, der henviser til:

1. Kildekontrolversion, der blev frigivet. For eksempel, hvis der var en frigivelse af revision nr. 12345, kan dette spores ved at have det som buildnummeret, og hvis det er patched, kan det være, hvor revisioner kan gå op, da det ikke er ny funktionalitet, der øger de større eller mindre versioner og build-nummeret skal huskes, hvis nogen vil køre den build igen.

2. Kontinuerlig integrationsserveridentifikator. I dette tilfælde kan CI-serveren nummerere hver build, den kører og dermed er build-nummeret, hvad en vellykket build får, og revisionsdelen er ikke nødvendig i dette scenarie.

Der kan være andre, som jeg ikke kender, men disse er de store, som jeg kender, når det kommer til tal på kodebaser.

Kommentarer

• +1 til nr. 1. Jeg kan godt lide at bruge revision af kildekontrol #, fordi det gør det meget nemmere at slå op på fejl, der er rapporteret mod den version i kildekontrol.
• @MasonWheeler: fungerer godt, hvis du er på SVN. Men når du kommer til dcvs lander det får egern y. Dette ville være en ting, jeg savner mest ved svn I ‘ ll tilføj.

Revisionen kan bruges til patches af bygger. Lad os sige, at 2 hold arbejder på et produkt.

Team 1 er det største udviklingsteam og producerer natlig build med følgende versionskema 1.0.X.0, hvor X er inkrementeret. Nu er de ved build 1.0.50.0 Team 2 tager en build fra tid til anden. Lad os sige, at de tager buildet fra sidste uge, som er 1.0.43.0 og begynder at bruge det. Team 1 går videre til 1.0.51.0, når team 2 finder et problem i 1.0.43.0.

Nu vil team 1 tage den build (43), rette problemet og give team 2 build 1.0.43.1. Fix rettes muligvis også i hovedbygningen, så ændringen vises i 1.0.52.0.

Håb dette er klart og nyttigt.

* Revision er nyttig, når ikke alle, der er involveret i projektet, bruger den samme build, og du har brug for at patchere specifikke builds.

Lad mig bare sige, hvordan jeg ser og bruger det ….

Programnavn version major.minor.build.revision

major: For mig er det nuværende projekt, jeg arbejder på. Nummeret ændres ikke, før jeg starter et nyt projekt med samme programnavn. Dette betyder, at jeg bogstaveligt talt skriver et nyt program af samme køn (eksempel: adgang v1 – adgang v-2 – få adgang til v-3 * alt det samme program, men fuldstændigt omskrevet).

mindre: Dette betyder, at jeg er annonce ting funktionalitet til det aktuelle offentliggjorte projekt.For eksempel har jeg måske tilføjet muligheden for at udskrive en kvittering eller tilføjet muligheden for at importere billeder. Dybest set yderligere funktionalitet, jeg vil tilføje nu og ikke vente på, at den næste store udgivelse gør det.

build: Dette bruger jeg til at indikere meget små ændringer i den offentliggjorte major.minor-version. Dette kan være en ændring i layoutet, farveskemaet osv.

revision: Dette bruger jeg til at indikere en fejlrettelse i den aktuelle offentliggjorte major.minor.build – Der er lejligheder, hvor jeg ikke udvikler nuværende projekt, og der opstår en fejl. Denne fejl skal rettes og offentliggøres. Det betyder bare, at jeg løser det, jeg allerede har offentliggjort, for at fungere korrekt. Jeg vil også bruge dette, hvis jeg arbejder på en ny build, en ny tilføjelse eller startede en ny større version. Den offentliggjorte version skal naturligvis lappes, mens vi venter på den næste større, mindre eller build-udgivelse.

Så på denne måde kan et færdigt eller stoppet projekt stadig løses og gøres brugbart, indtil den næste udgivelse er offentliggjort.

Jeg håber, at dette giver nogen en bedre forståelse af, hvordan denne type versionering vil (eller bør) fungere. For mig er det den eneste definition og praksis, der giver enhver form for reel mening, når man bruger denne type versionering.

Jeg har kun nogensinde set et build-nummer som det sidste nummer i frigivelses-idet. Jeg er ikke sikker på, hvordan du ville komme med en revision til et build-nummer. Jeg formoder, at hvis du ændrede nogle af de ikke-byggede ressourcer ( ikoner, DB-script osv.), måske, men de fleste projekter, jeg har arbejdet med for nylig, har også alle de ting, der er under versionskontrol, så byggeprocessen henter dem, når jeg laver installationsprogrammet / frigivelsen. Jeg kan godt lide tidsstemplede buildnumre, men ikke helt som @David beskriver (jeg kan godt lide major.minor.revision.HHMM). Men hvor jeg arbejder, bruger vi bare et løbenummer, som vores build-server genererer.

Det er hvad du vil det skal være. Jeg har en tendens til at bruge år.månedag.hhmm til min store.minor.bygning.vision. Hvis jeg producerer mere end en i minuttet, er der noget galt. du kan bare bruge et simpelt trin, ellers har jeg set nogle detaljerede generatorer til dem. Hvad vil du have det til at være. Hvad de skal gøre er at gøre det, så du kommer til den kilde, der bruges til Opret det output, så hvad som helst, der gør det muligt for dig.

Vores team bruger det tredje nummer (revision) som revisionsnummer fra Subversion-arkivet. Vi bruger det fjerde nummer (build) som build-nummeret fra vores TeamCity kontinuerlige integrationsserver, der faktisk opretter buildet. TeamCity opretter en ny AssemblyInfo-fil med de rigtige #er i løbet af buildprocessen.

Ligesom jkohlhepp bruger vi den tredje del af versionen til at vise revisionsnummeret i SubVersion og den fjerde til at vise build-nummer fra vores kontinuerlige integrationsserver (Jenkins for os). Dette giver os flere fordele – at have det versionsnummer, der er indstillet af vores CI-server, fjerner et manuelt trin, der ellers kunne være tilfældigt savnet; det er let at kontrollere, at en udvikler ikke har foretaget en fræk frigivelse fra deres udviklings-pc (hvilket ville resultere i, at disse tal er nul); og det giver os mulighed for at binde ethvert stykke software tilbage til både koden, som den blev genereret fra og det CI-job, der byggede det, bare ved at se på versionsnummeret – hvilket vi lejlighedsvis finder meget nyttigt.

De sidste to cifre er det samlede build-nummer

1.01.2.1234

build-nummeret er 2.1234, men de fleste bruger bare 1234, da 2-delen ikke ændres ofte.

Kommentarer

• OP spørger, hvad der er build-nummeret, ikke hvilket er build-nummeret i revision-idet.