Wat is precies het buildnummer in MAJOR.MINOR.BUILDNUMBER.REVISION

Ik heb het nog nooit in die vorm geschreven gezien. Waar ik werk, gebruiken we het formulier MAJOR.MINOR.REVISION.BUILDNUMBER, waarbij:

• MAJOR een grote release is (meestal veel nieuwe functies of wijzigingen in de gebruikersinterface of onderliggende OS)
• MINOR is een kleine uitgave (misschien enkele nieuwe functies) op een eerdere grote uitgave
• REVISIE is meestal een oplossing voor een eerdere secundaire uitgave (geen nieuwe functionaliteit)
• BUILDNUMBER wordt verhoogd voor elke laatste build van een revisie.

Een revisie kan bijvoorbeeld worden vrijgegeven voor QA (kwaliteitscontrole), en ze komen terug met een probleem dat vereist een verandering. De bug zou worden gerepareerd, en teruggebracht naar QA met hetzelfde REVISION-nummer, maar een verhoogd BUILDNUMBER.

Opmerkingen

• +1: Dat ‘ is ongeveer zoals ik ‘ het ook overal elders heb gezien. Ik ‘ heb gezien en vond het leuk hoe sommige bedrijven gewoon een DateTime-stempel gebruiken voor de BUILDNUMBER.
• +1: De ” MAJOR.MINOR.REVISION.BUILDNUMBER ” vorm is begrijpelijk en logisch. Ik zag het BUILDNUMBER.REVISION-formulier op de MSDN-site (link bijgewerkt in de vraag) en het bracht me totaal in de war.
• Vreemd. Ik zou verwachten dat herziening als laatste het meest logisch is – het is ‘ het nummer dat (waarschijnlijk) het meest zal veranderen.
• @Izkata, eigenlijk de build nummer verandert het meest, althans de manier waarop we het nu gebruiken bij mijn hoofdcontract dat strikte versiecontrole gebruikt omdat we medische apparaten maken. Een bijgewerkte revisie geeft aan dat er een oplossing is voor de vorige software, die moet worden getest door QA (Quality Assurance). Dit is een volledig aparte afdeling die drie dagen lang uitgebreide tests uitvoert (volgens FDA-richtlijnen). Als ze problemen vinden, kunnen aanvullende codewijzigingen nodig zijn, waarvoor een nieuwe build (opnieuw compileren en koppelen) en vervolgens opnieuw testen vereist is, maar het revisienummer blijft hetzelfde.
• @tcrosley Ik denk dat het ‘ is een geval van onduidelijke terminologie. Ik dacht aan revisies in versiebeheer.

De hele verwarring komt voort uit de verschillende semantiek die MS gebruikt voor “Build-nummer” en vooral “Revisie”. De termen betekenen gewoon verschillende dingen.

De meeste mensen (inclusief ikzelf) gebruiken een semantisch versienummeringsschema waar je gewoon een hoger BUILD-nummer krijgt wanneer je om wat voor reden dan ook een nieuwbouw moet maken. Voor ons wordt een hotfix beschouwd als een nieuwe codewijziging, en het BUILD-gedeelte neemt automatisch toe met elke CI-run. Modules met dezelfde MAJ.MIN.REV worden als uitwisselbaar beschouwd en de BUILD vertelt u welke de meest recente is.

Toenemende REVISION duidt echter op een nieuwe permanente releasetak, daarom plaatsen we deze voor BUILD.Het nadeel van die benadering is dat we de volgende reeks gebeurtenissen kunnen krijgen:

• commit nummer 4711: Alice heeft feature A toegevoegd
• CI produceert build 1.2.3.100
• commit nummer 4712: Bob heeft feature B gewijzigd
• commit nummer 4713: Alice vaste feature A (de “hotfix”)
• CI produceert build 1.2.3.101

Zoals u kunt zien, is de hotfix niet de enige wijziging in de volgende build, wordt ook de modificatie van Bob onderdeel van die build. Als je de huidige branch wilt stabiliseren, kun je problemen tegenkomen omdat je nooit zeker weet of Bob net een aantal bugs heeft toegevoegd.

MS gebruikt beide termen anders. Het BUILD-nummer wordt niet automatisch opgehoogd, maar kan worden beschouwd als een soort releasetak, om de code die voor een bepaalde versie van de code wordt gebruikt, te bevriezen. De REVISION geeft aanvullende “hot” wijzigingen aan die zijn toegepast op die BUILD-tak. De volgorde zou daarom als volgt zijn:

• commit nummer 4711: Alice heeft feature A toegevoegd aan trunk / master
• Carl maakt build branch 1.2.100
• CI produceert build 1.2.100.0
• vastlegnummer 4712: Bob heeft kenmerk B in stam / master gewijzigd
• vastlegnummer 4713: Alice vast kenmerk A in de 1.2.100 branch
• CI produceert build 1.2.100.1

De term REVISION kan verwijzen naar

• een product revisie (zo gebruiken de meeste mensen het)
• een herziening van een bepaalde dagelijkse build (dat is wat MS doet)

Het belangrijkste verschil tussen de twee processen is of je de mogelijkheid wilt hebben om hotfixes toe te passen op CI-builds en dus op welk punt in het proces de aftakking wordt gemaakt. Dit aspect wordt belangrijk wanneer u op elk moment een bepaalde build wilt kunnen kiezen nadat alle tests zijn geslaagd en precies die versie wilt promoten naar de volgende officiële release van uw product.

In ons geval maakt de CI-tool een repository-tag aan, zodat we altijd de nodige informatie bij de hand hebben, wanneer dat nodig is. Met SVN wordt het zelfs nog eenvoudiger, omdat tags en branches op precies dezelfde manier worden geïmplementeerd – een tag is niets meer dan een branch die zich bevindt onder /tags.

Zie ook

Van de FAQ-sectie op TFS vertakkingsstrategie :

In welke branch moet ik het P1 (hotfix) -ticket repareren?

• De P1 moet worden gerepareerd in de branch die het dichtst bij de codebasis in Production ligt. In dit geval moet de P1 worden gefixeerd in de Prod-tak. Door de fix in een andere branch toe te passen en de wijzigingen in de productie uit te rollen, loop je het risico om halfafgewerkte of niet-geteste code vrij te geven uit de volgende iteraties.

• Nu kun je discussiëren of het veilig om rechtstreeks tegen de Prod-tak te werken, denk nogmaals, een P1 die onmiddellijke aandacht vereist, zou geen fundamenteel probleem in het systeem moeten zijn. In het geval dat het een fundamenteel probleem is, moet het worden toegevoegd aan de Product backlog, aangezien het mogelijk verdere analyse en discussie met de klant vereist.

Een ander goed gelezen is de TFS branching guide

Reacties

• Dit is een geweldig antwoord! +1

Microsoft beschrijft het doel van elk onderdeel van een .NET-versienummer in hun MSDN-documentatie voor de Version klasse. Hier is het relevante gedeelte:

major.minor [.build [.revision]]

De componenten worden volgens afspraak gebruikt als volgt:

Major: Assemblies met dezelfde naam maar verschillende hoofdversies zijn niet uitwisselbaar. Een hoger versienummer kan duiden op een ingrijpende herschrijving van een product waarbij achterwaartse compatibiliteit niet kan worden aangenomen.

Klein: als de naam en het hoofdversienummer op twee assemblages hetzelfde zijn, maar het secundaire versienummer is anders, dit duidt op een aanzienlijke verbetering met de bedoeling van achterwaartse compatibiliteit. Dit hogere secundaire versienummer kan duiden op een puntrelease van een product of een volledig achterwaarts compatibele nieuwe versie van een product.

Build: een verschil in buildnummer vertegenwoordigt een hercompilatie van dezelfde bron. Er kunnen verschillende buildnummers worden gebruikt als de processor, het platform of de compiler verandert.

Revisie: Assemblies met dezelfde naam, hoofd- en secundaire versienummers, maar verschillende revisies zijn bedoeld om volledig uitwisselbaar te zijn. Een hoger revisienummer kan worden gebruikt in een build die een beveiligingslek in een eerder uitgebrachte assembly oplost.

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

Reacties

• Het verbaast me waarom niemand deze standaard kent, elk antwoord hier beweert build aan het einde en niet ‘ t begrijpen dat revisie heel eenvoudig is; het betekent hotfix. Je geeft een build vrij en maakt vervolgens verdere builds, maar wanneer je terug moet gaan en die release moet repareren, werk je de revisie bij om te laten zien dat de specifieke build die is uitgebracht, is gewijzigd voor een nieuwe release.
• +1 voor een antwoord met een gerechtvaardigd buildnummer. Alleen het aantal verhogen is tamelijk nutteloos als de revisie hetzelfde blijft (tenzij je een waanzinnig build-systeem hebt dat tijdafhankelijk is). Het buildnummer gebruiken om aan te geven welke compiler, platforms, enz. is nuttig.
• Build als een recompilation of the same source lijkt een belangrijk punt te zijn dat wordt gemist. Als het ‘ een codewijziging is (dat ‘ niet een geheel nieuwe grote / kleine toename vereist), dan is de Revision moet ook worden gewijzigd.
• @PeterX Zoals in het geval van build-specifieke wijzigingen bij opnieuw targeten?
• ” Een verschil in buildnummer vertegenwoordigt een hercompilatie van dezelfde bron ” lijkt in tegenspraak met de documentatie. Als je eenmaal een revisie hebt gemaakt, is het niet langer dezelfde bron. BOUWEN vóór REVISIE heeft alleen zin als een revisie specifiek is voor een build die een ” processor-, platform- of compilerverandering ” vertegenwoordigt. Dus ik denk dat wat de meesten zien als een REVISIE-hobbel, echt een KLEINE hobbel zou moeten zijn bij het gebruik van deze beschrijvingen. Hoewel de documenten het gebruik van REVISION voor hotfixs vermelden, maar Id veronderstelt dat hotfixs van toepassing zijn op alle builds, en daarom een KLEINE hobbel zouden moeten zijn. Ik wil gewoon wat logische consistentie !!

Er zijn op zijn minst een paar verschillende dingen die ik zou kunnen doen stel je het buildnummer voor dat verwijst naar:

1. Broncontroleversie die was vrijgegeven. Als er bijvoorbeeld een release was van revisie # 12345, kan dit worden gevolgd door het buildnummer te hebben en als het wordt gepatcht, kunnen revisies daar omhoog gaan, omdat het geen nieuwe functionaliteit is die de hoofd- of secundaire versies zou verhogen en het buildnummer moet worden onthouden voor het geval iemand die build opnieuw wil uitvoeren.

2. Identifier voor continue integratieserver. In dit geval kan de CI-server elke build nummeren die wordt uitgevoerd en dus is het buildnummer wat een succesvolle build krijgt en het revisiegedeelte is niet nodig in dit scenario.

Er kunnen andere zijn die ik niet ken, maar dit zijn de belangrijkste die ik ken als het gaat om getallen op codebases.

Reacties

• +1 voor # 1. Ik gebruik graag de source control revision #, omdat het zo veel gemakkelijker maakt om bugs op te zoeken die tegen die versie zijn gerapporteerd in source control.
• @MasonWheeler: werkt geweldig als je op SVN zit. Maar als je bij dcvs komt, land het krijgt eekhoorn y. Dit zou iets zijn dat ik het meest mis aan svn I ‘ ll toevoegen.

Een buildnummer wordt gewoonlijk bij elke build opgehoogd, zodat het uniek is.

Voor de eenvoud resetten sommigen het buildnummer telkens wanneer de MAJOR- of MINOR-nummers worden gestoten.

De meeste Continuous Integration-engines staan automatisch gegenereerde unieke buildnummers toe.

De revisie kan worden gebruikt voor patches van de bouwt. Laten we zeggen dat 2 teams aan een product werken.

Team 1 is het belangrijkste ontwikkelingsteam en produceert nachtelijke build met het volgende versieschema 1.0.X.0, waarbij X wordt opgehoogd. Nu zijn ze bij build 1.0.50.0. Team 2 maakt van tijd tot tijd een build. Laten we zeggen dat ze de build van vorige week, 1.0.43.0, nemen en deze gaan gebruiken. Team 1 gaat door naar 1.0.51.0 wanneer team 2 een probleem vindt in 1.0.43.0.

Nu zal team 1 neem die build (43), los het probleem op en voorzie team 2 van build 1.0.43.1. De correctie kan ook worden gepropageerd in de hoofdbuild, dus de wijziging zal verschijnen in 1.0.52.0.

Hoop dit is duidelijk en nuttig.

* Revisie is handig wanneer niet iedereen die bij het project betrokken is dezelfde build gebruikt en u specifieke builds moet patchen.

Laat me gewoon zeggen hoe ik het zie en gebruik ….

Programmanaam versie major.minor.build.revision

major: Voor mij is dit het huidige project waaraan ik werk. Het nummer verandert niet totdat ik een nieuw project start met dezelfde programmanaam. Dit betekent dat ik letterlijk een nieuw programma van hetzelfde geslacht ga schrijven (voorbeeld: access v1 – toegang tot v-2 – toegang tot v-3 * allemaal hetzelfde programma maar volledig herschreven).

minor: dit betekent dat ik een advertentie ben functionaliteit toevoegen aan het huidige gepubliceerde project.Misschien heb ik bijvoorbeeld de mogelijkheid toegevoegd om een bon af te drukken of de mogelijkheid toegevoegd om afbeeldingen te importeren. Eigenlijk extra functionaliteit die ik nu wil toevoegen en niet wacht tot de volgende grote release het doet.

build: Dit gebruik ik om zeer kleine wijzigingen in de gepubliceerde major.minor-versie aan te geven. Dit kan een wijziging zijn in de lay-out, het kleurenschema, enz.

herziening: Dit gebruik ik om een bugfix in de huidige gepubliceerde major.minor.build aan te duiden – Er zijn gevallen waarin ik niet verder ga met huidige project en een bug doet zich voor. Deze bug moet worden opgelost en gepubliceerd. Het betekent gewoon dat ik repareer wat ik al heb gepubliceerd, zodat het correct werkt. Ik zou dit ook gebruiken als ik bezig ben met een nieuwe build, een nieuwe toevoeging of als ik aan een nieuwe hoofdversie ben begonnen. De gepubliceerde versie moet uiteraard worden gepatcht terwijl we wachten op de volgende grote, secundaire of build-release.

Dus op deze manier kan een voltooid of vastgelopen project nog steeds worden gerepareerd en bruikbaar worden gemaakt tot de volgende release gepubliceerd.

Ik hoop dat dit iemand een beter begrip geeft van hoe dit type versiebeheer zou (of zou moeten) werken. Voor mij is het de enige definitie en oefening die echt zin heeft bij het gebruik van dit type versiebeheer.

Ik heb alleen ooit een buildnummer gezien als het laatste nummer in de release-ID. Ik weet niet zeker hoe je een revisie van een buildnummer zou verzinnen. Ik veronderstel dat als je enkele van de niet-gebouwde bronnen ( pictogrammen, DB-script, enz.), misschien, maar de meeste projecten waaraan ik onlangs heb gewerkt, hebben al die dingen ook onder versiebeheer, dus het bouwproces pikt ze op bij het maken van het installatieprogramma / de release. Ik hou van buildnummers met tijdstempel, hoewel niet helemaal zoals @David beschrijft (ik hou van major.minor.revision.HHMM). Waar ik werk, gebruiken we echter gewoon een volgnummer dat onze build-server genereert.

Het is wat je maar wilt het te zijn. Ik gebruik meestal jaar.maand.dag.hhmm voor mijn major.minor.build.revision. Als ik meer dan één minuut per minuut produceer, is er iets mis. je kunt gewoon een simpele stap gebruiken, of ik heb een paar uitgebreide generatoren voor ze gezien. Wat willen jij dat het is? Wat ze moeten doen, is ervoor zorgen dat je bij de bron komt creëer die output, dus wat je ook maar in staat stelt om dat te doen.

Ons team gebruikt het derde nummer (revisie) als de revisienummer van de Subversion-repository. We gebruiken het vierde nummer (build) als het buildnummer van onze TeamCity continue integratieserver die de build daadwerkelijk maakt. TeamCity maakt een nieuw AssemblyInfo-bestand met de juiste #s erin tijdens het buildproces.

Net als jkohlhepp gebruiken we het derde deel van de versie om het revisienummer in SubVersion te tonen en het vierde om de buildnummer van onze continue integratieserver (Jenkins voor ons). Dit geeft ons een aantal voordelen: als het versienummer is ingesteld door onze CI-server, wordt een handmatige stap verwijderd die anders per ongeluk gemist; het is gemakkelijk om te controleren of een ontwikkelaar geen brutale release heeft gedaan vanaf zijn ontwikkel-pc (wat ertoe zou leiden dat deze cijfers nul zijn); en het stelt ons in staat om elk stuk software terug te koppelen aan zowel de code die het is gegenereerd met als de CI-taak die het heeft gemaakt, gewoon door naar het versienummer te kijken – wat we af en toe erg handig vinden.

De laatste twee cijfers zijn het totale buildnummer

1.01.2.1234

het buildnummer is 2.1234, maar de meeste mensen zullen 1234 gewoon gebruiken omdat het 2-deel niet vaak verandert.

Opmerkingen

• Het OP vraagt wat het buildnummer is, niet wat het buildnummer in de revisie-ID is.