Mikä tarkalleen on mallin MAJOR.MINOR.BUILDNUMBER.REVISION

En ole koskaan nähnyt sitä kirjoitettuna siinä muodossa. Työssäni käytämme muotoa MAJOR.MINOR.REVISION.BUILDNUMBER, jossa:

• MAJOR on merkittävä julkaisu (yleensä monia uusia ominaisuuksia tai muutoksia käyttöliittymään tai käyttöjärjestelmä)
• MINOR on vähäinen julkaisu (ehkä joitain uusia ominaisuuksia) edellisestä suuresta julkaisusta
• REVISION on yleensä korjaus edelliseen pieneen julkaisuun (ei uutta toimintoa)
• RAKENNUSLUKU kasvaa jokaisen viimeisimmän version koontiversion kohdalla.

Esimerkiksi versio voidaan luovuttaa laadunvalvontaan (laadunvalvonta), ja he palaavat ongelman, joka vaatii muutosta. Virhe korjataan ja vapautetaan takaisin laadunvalvontaan samalla REVISION-numerolla, mutta kasvava BUILDNUMBER.

Kommentit

• +1: Tämä ’ s melkein samalla tavalla kuin minä ’ olen nähnyt sen myös muualla. Olen ’ nähnyt ja pitänyt siitä, kuinka jotkut yritykset käyttävät vain DateTime-leimaa rakennukselle.
• +1: ” MAJOR.MINOR.REVISION.BUILDNUMBER ” -lomake on ymmärrettävä ja järkevä. Näin BUILDNUMBER.REVISION-lomakkeen MSDN-sivustolla (linkki päivitettiin kysymyksessä) ja se hämmentää minua täysin.
• Pariton. Odotan, että tarkistus on viimeinen järkevin – se ’ on numero, joka (todennäköisesti) muuttuu eniten.
• @Izkata, itse asiassa rakennus numero muuttuu eniten, ainakin tapa, jolla käytämme sitä tällä hetkellä pääsopimuksessani, joka käyttää tiukkaa versionhallintaa, koska teemme lääkinnällisiä laitteita. Päivitetty versio osoittaa, että edelliseen ohjelmistoon on tehty korjaus, jonka QA (Quality Assurance) on testattava. Tämä on täysin erillinen osasto, joka tekee laajaa testausta kolmen päivän ajan (FDA: n ohjeiden mukaan). Jos he löytävät ongelmia, koodin muutokset saattavat olla tarpeen, mikä edellyttää uutta koontiversiota (uudelleen kääntäminen ja linkittäminen) ja sitten uudelleentestausta, mutta versionumero pysyy samana.
• @tcrosley Luulen, että se ’ sa epäselvä terminologia. Ajattelin versiohallinnan versioita.

Koko hämmennys johtuu erilaiset semantiikat , joita MS käyttää ”koontinumero” ja erityisesti ”versio”. Termit tarkoittavat vain erilaisia asioita.

Useimmat ihmiset (minä mukaan lukien) käyttävät semanttisen version numerointijärjestelmää , jossa saat vain suuremman BUILD-numeron. aina kun joudut tekemään uuden rakennelman mistä tahansa syystä. Meille hotfix-korjausta pidetään vain yhtenä koodimuutoksena, ja BUILD-osa kasvaa automaattisesti jokaisen CI-ajon aikana. Moduuleja, joilla on sama MAJ.MIN.REV, pidetään vaihdettavissa, ja BUILD kertoo, kumpi on uusin.

Lisääntyvä REVISION osoittaa kuitenkin uuden pysyvän julkaisuhaaran, minkä vuoksi asetamme sen BUILDin eteen.Tämän lähestymistavan haittapuoli on, että saatamme saada seuraavan tapahtumasarjan:

• sitoutu numero 4711: Alice lisäsi ominaisuuden A
• CI tuottaa koontiversion 1.2.3.100
• sitoutumisnumero 4712: Bobin muokkaama ominaisuus B
• sitouttamisnumero 4713: Alice-kiinteä ominaisuus A (”hotfix”)
• CI tuottaa koontiversion 1.2.3.101

Kuten näette, hotfix-korjaus ei ole ainoa muutos, joka sisältyy seuraavaan rakentaa, myös Bobin muunnoksista tulee osa tätä koontiversiota. Jos haluat vakauttaa nykyisen haaran, saatat törmätä ongelmiin, koska et voi koskaan olla varma, lisäsikö Bob vain joukon vikoja vai ei.

MS käyttää molempia termejä eri tavalla. BUILD-numeroa ei lisätä automaattisesti, vaan sen voidaan pitää eräänlaisena julkaisuhaarana, joka jäädyttää koodin tietylle versiolle käytetyn koodin. REVISION osoittaa lisää ”kuumia” muutoksia, jotka on tehty kyseiseen BUILD-haaraan. Sekvenssi olisi näin ollen seuraava:

• sitouttaminen numero 4711: Alice lisäsi ominaisuuden A runkoon / pääkoneeseen
• Carl luo rakennushaaran 1.2.100
• CI tuottaa koontiversion 1.2.100.0
• sitouttamisnumero 4712: Bobin muokkaama ominaisuus B tavaratilassa / isännässä
• sitouttamisnumero 4713: Alice-kiinteä ominaisuus A 1.2.100 -haarassa
• CI tuottaa koontiversion 1.2.100.1

Termi REVISION voi viitata

• a tuotteeseen tarkistus (useimmat ihmiset käyttävät sitä)
• tietyn päivittäisen version (sitä MS tekee)

Keskeinen ero näiden kahden prosessin välillä on, haluatko kykyä soveltaa hotfix-korjauksia CI-rakenteisiin, ja missä prosessin vaiheessa haara tehdään. Tästä näkökulmasta tulee tärkeä, kun haluat pystyä valitsemaan tietyn rakennelman milloin tahansa kaikkien testien onnistuttua ja mainostamaan täsmälleen kyseisen version tuotteesi seuraavaan viralliseen julkaisuun.

Meidän tapauksessamme CI-työkalu luo arkistotunnisteen, joten meillä on aina tarvittavat tiedot valmiina käytettäväksi tarvittaessa. SVN: n avulla siitä tulee vielä yksinkertaisempi, koska tunnisteet ja haarat toteutetaan täsmälleen samalla tavalla – tagi on vain haara, joka sijaitsee /tags -kohdassa.

Katso myös

Usein kysytyt kysymykset -osiosta kohdassa TFS-haaroitusstrategia :

Missä haarassa minun pitäisi korjata P1 (hotfix) -lippu?

• P1 tulisi kiinnittää haaraan, joka on lähinnä Tuotannossa toimivaa koodipohjaa. Tässä tapauksessa P1 tulisi kiinnittää Prod-haaraan. Käyttämällä korjausta missä tahansa muussa haarassa ja ottamalla käyttöön muutokset tuotantoon saatat vapauttaa puolivalmiita tai testaamattomia koodeja seuraavista iteraatioista.

• Nyt voit väittää, onko se turvallista työskennellä suoraan Prod-haaraa vastaan, ajattele uudestaan, välitöntä huomiota vaativa P1 ei saisi olla järjestelmän perusongelma. Jos kyseessä on olennainen ongelma, se on lisättävä tuotekantaan, koska se saattaa edellyttää lisäanalyyseja ja keskusteluja asiakkaan kanssa.

Toinen hyvä lukema on TFS-haaroitusopas

Kommentit

• Tämä on hieno vastaus! +1

Microsoft kuvaa .NET-versionumeron jokaisen komponentin tarkoituksen MSDN-dokumentaatiossa luokalle Version. Tässä on asiaankuuluva osa:

major.minor [.build [.revision]]

Komponentteja käytetään sopimuksessa seuraa:

Major: Kokoonpanoja, joilla on sama nimi, mutta erilaiset pääversiot, ei voi vaihtaa keskenään. Suurempi versionumero saattaa tarkoittaa tuotteen suurta uudelleenkirjoitusta, jossa yhteensopivuutta ei voida olettaa.

Pienet: Jos kahden kokoonpanon nimi ja pääversionumero ovat samat, mutta pienen versionumero on erilainen, tämä osoittaa merkittävää parannusta taaksepäin yhteensopivuuden tarkoituksella. Tämä korkeampi pienempi versionumero saattaa viitata tuotteen pisteversioon tai tuotteen täysin taaksepäin yhteensopivaan uuteen versioon.

Koontiversio: Rakennusnumeron ero tarkoittaa saman lähteen uudelleen kääntämistä. Eri koontinumeroita voidaan käyttää, kun prosessori, alusta tai kääntäjä muuttuu.

Versio: Kokoonpanot, joilla on sama nimi, isompi ja pienempi versionumero, mutta eri versiot on tarkoitettu täysin vaihdettaviksi. Suurempaa versionumeroa voidaan käyttää rakennuksessa, joka korjaa aiemmin julkaistun kokoonpanon turva-aukon.

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

Kommentit

• Se hämmentää minua, miksi kukaan ei tiedä tätä standardia, jokainen tässä väitetty vastaus, jonka mukaan koontiversio menee loppuun ja ei ’ t ymmärtää, että tarkistus on hyvin yksinkertaista; se tarkoittaa korjausta. Vapautat koontiversio ja luot sitten uudet koontiversiot, mutta kun sinun on palattava takaisin ja korjattava kyseinen julkaisu, päivität version näyttämään, että julkaistua koontiversiota muutettiin uudelle versiolle
• +1 käyttäjälle vastaus, jolla on perusteltava koontinumero. Pelkkä numeron lisääminen on melko hyödytöntä, jos versio pysyy samana (ellei sinulla ole järjetöntä rakennusjärjestelmää, joka on ajasta riippuvainen). Rakennenumeron avulla ilmoitetaan kääntäjästä, alustoista jne. on hyödyllistä.
• Build recompilation of the same source näyttää olevan tärkeä asia, joka jää väliin. Jos se ’ sa-koodin muutos (joka ei vaadi ’ t vaadi kokonaan uutta suurempaa / pienempää lisäystä), niin Revision on myös muutettava.
• @PeterX Kuten rakennuskohtaisissa muutoksissa kohdennettaessa uudelleen?
• ” Koontiluvun ero tarkoittaa saman lähteen uudelleen kääntämistä. ” näyttää olevan ristiriidassa dokumentaation kanssa. Kun olet tehnyt version, se ei ole enää sama lähde. RAKENTAMINEN ennen REVISIONia on järkevää vain, jos versio on ominaista rakennukselle, joka edustaa ” -prosessoria, -alustaa tai kääntäjän muutosta ”. Joten luulen, että useimpien REVISION-kolahdusten pitäisi olla todella MINOR-kolhuja käytettäessä näitä kuvauksia. Vaikka asiakirjoissa mainitaan REVISIONin käyttö hotfix-korjauksissa, mutta Id olettaa, että hotfix-korjauksia sovelletaan kaikkiin koontiversioihin, ja siksi niiden on oltava Pieni virhe. Haluan vain loogista johdonmukaisuutta!

Voisin ainakin pari erilaista asiaa kuvittele koontiversioiden viittauksia:

1. Lähdeohjausversio, joka julkaistiin. Esimerkiksi jos versio # 12345 julkaistiin, sitä voidaan seurata antamalla sen koontiversion numero ja jos se on korjattu, versiot voivat nousta ylöspäin, koska se ei ole uusi toiminnallisuus, joka lisäisi suuria tai pienempiä versioita ja koontiversio on muistettava, jos joku haluaa suorittaa kyseisen rakennuksen uudelleen.

2. Jatkuva integrointipalvelimen tunniste. Tällöin CI-palvelin voi numeroida jokaisen suorittamansa rakennelman ja siten koontiversio on se, mitä onnistunut koontiversio saa, ja tarkistusosaa ei tarvita tässä skenaariossa.

Voi olla muita, joita en tiedä, mutta nämä ovat suuret, jotka tiedän, kun on kyse koodipohjaisista numeroista.

Kommentit

• +1 kohteelle # 1. Haluan käyttää lähdekontrollin versio #, koska sen avulla on paljon helpompaa etsiä kyseistä versiota vastaan ilmoitettuja vikoja lähdekoodin hallinnassa.
• @MasonWheeler: toimii hyvin, jos olet SVN: ssä. Mutta kun pääset dcv-levyihin, laske se saa oravan y. Tämä olisi yksi asia, jota kaipaan eniten svn: stä I ’ ll add.

Rakennenumeroa lisätään yleensä jokaisessa koontiversiossa, joten se on yksilöllinen.

Yksinkertaisuuden vuoksi jotkut palauttavat rakennenumeron aina, kun MAJOR- tai MINOR-numerot koputetaan.

Suurin osa jatkuvan integroinnin moottoreista sallii automaattisen tuotannon yksilölliset koontiluvut.

Versiota voidaan käyttää rakentaa. Sanotaan, että 2 tiimiä työskentelee tuotteen parissa.

Tiimi 1 on tärkein kehitystiimi ja tuottaa iltaisin koontiversiota seuraavalla versiokaavalla 1.0.X.0, jossa X: ää lisätään. Nyt he ovat rakenteessa 1.0.50.0. Joukkue 2 ottaa ajoittain rakennetta. Sanotaan, että he ottavat viime viikosta version 1.0.43.0 ja alkavat käyttää sitä. Joukkue 1 etenee versioon 1.0.51.0, kun joukkue 2 löytää ongelman versiossa 1.0.43.0.

Nyt joukkue 1 ota se koontiversio (43), korjaa ongelma ja toimita tiimille 2 koontiversio 1.0.43.1.Korjaus saatetaan levittää myös päärakennuksessa, joten muutos näkyy versiossa 1.0.52.0.

Hope tämä on selkeä ja hyödyllinen.

* Versio on hyödyllinen, kun kaikki projektissa mukana olevat käyttäjät eivät käytä samaa koontiversiota ja sinun on korjattava tietyt koontiversiot.

Haluan vain sanoa, miten näen ja käytän sitä ….

Ohjelmanimen versio major.minor.build.revision

pääaine: Minulle on meneillään oleva projekti, jonka parissa työskentelen. Numero ei muutu ennen kuin aloitan uuden saman nimisen projektin. Tämä tarkoittaa, että kirjoitan kirjaimellisesti uuden saman sukupuolen ohjelman (esimerkki: access v1 – access v-2 – access v-3 * kaikki sama ohjelma, mutta kirjoitettu kokonaan uudestaan).

minor: Tämä tarkoittaa, että olen mainos toiminnallisuutta nykyiseen julkaistuun projektiin.Esimerkiksi ehkä lisäsin mahdollisuuden tulostaa kuitti tai kyky tuoda kuvia. Pohjimmiltaan lisätoiminnot, jotka haluan lisätä nyt enkä odota seuraavaa suurta julkaisua.

koontiversio: Tätä käytän osoittamaan hyvin pieniä muutoksia julkaistuun major.minor-versioon. Tämä voi olla muutos asettelussa, värimaailmassa jne.

versio: Tätä käytän osoittamaan virhekorjauksen nykyisessä julkaistussa major.minor.build -viesteissä – On tilanteita, joissa en edetä nykyinen projekti ja ilmenee virhe. Tämä vika on korjattava ja julkaistava. Se tarkoittaa vain sitä, että korjaan jo julkaisemani toimimaan kunnolla. Käytän tätä myös, jos olen tekemässä uutta rakennetta, uutta lisäystä tai aloittanut uuden suuren version. Julkaistut versiot on tietysti korjattava, kun odotamme seuraavaa suurta, pienempää tai koontiversiota.

Joten tällä tavalla valmis tai jumissa oleva projekti voidaan silti korjata ja tehdä käyttökelpoiseksi seuraavaan julkaisuun saakka. julkaistu.

Toivon, että tämä antaa jollekulle paremman käsityksen siitä, miten tämän tyyppinen versiointi toimisi (tai pitäisi) toimia. Minulle se on ainoa määritelmä ja käytäntö, jolla on minkäänlaista todellista järkeä käytettäessä tällaista versiointia.

Olen vain koskaan nähnyt koontiluvun viimeisenä numerona julkaisutunnuksessa. En ole varma, kuinka tulisit muokkaamaan koontiluvun numeroa. Oletan, että jos muuttaisit joitain rakentamattomia resursseja ( kuvakkeet, DB-komentosarja jne.), ehkä, mutta useimmissa projekteissa, joissa olen viime aikoina työskennellyt, kaikki nämä asiat ovat myös versionhallinnan alla, joten rakennusprosessi poimi ne tehdessäsi asennusohjelmaa / julkaisua. Pidän aikaleimatuista koontinumeroista, vaikkakaan ei aivan kuten @David kuvaa (tykkään major.minor.revision.HHMM). Siellä missä työskentelen, käytämme kuitenkin vain järjestysnumeroa, jonka rakentamispalvelimemme luo.

Se on mitä haluat sen on oltava. Minulla on tapana käyttää vuotta.kuukausi.päivä.hhmm suurempaan.minor.build.revisionissani. Jos tuotan enemmän kuin yhden minuutin, jotain on vialla. voit käyttää vain yksinkertaista lisäystä, tai olen nähnyt heille joitain monimutkaisia generaattoreita. Mitä haluat haluat sen olevan. Mitä heidän on tehtävä, on tehdä se niin, että pääset tottuneeseen lähteeseen luo tuotos, joten mitä tahansa voit tehdä sen.

Tiimimme käyttää kolmatta numeroa (versio) versionumero Subversion-arkistosta. Käytämme neljää numeroa (koontia) kokoamisnumerona TeamCity-jatkuvan integraation palvelimeltamme, joka tosiasiallisesti luo koontiversion. TeamCity luo uuden AssemblyInfo-tiedoston, jossa on oikeat # -merkit rakennuksen aikana. / p>

Kuten jkohlhepp, käytämme version kolmatta osaa näyttämään versionumeron SubVersionissa ja neljännen osoittamaan koontinumero jatkuvan integraation palvelimeltamme (Jenkins meille) .Tämä antaa meille useita etuja – CI-palvelimemme asettaman versionumeron poistaminen poistaa manuaalisen vaiheen, joka muuten voisi vahingossa tapahtua jäänyt väliin; on helppo tarkistaa, että kehittäjä ei ole tehnyt räikeää julkaisua kehitystietokoneestaan (mikä johtaisi siihen, että nämä luvut olisivat nollia); ja sen avulla voimme sitoa minkä tahansa ohjelmiston takaisin sekä koodiin, jonka se luotiin , että sen rakentaneeseen CI-työhön, katsomalla versionumeroa – joka on toisinaan erittäin hyödyllinen.

Kaksi viimeistä numeroa ovat koontiluvun kokonaismäärä

1.01.2.1234

koontiluku on 2.1234, mutta useimmat ihmiset käyttävät vain 1234: tä, koska 2 osa ei muutu usein.

Kommentit

• OP kysyy mikä on koontiversio, ei mikä versiotunnuksessa oleva koontinumero.