Release cycle sv SE

Släpp cykel

ASF använder gemensam C# version med 4 siffror, skrivna som A.B.C.D. Givet version är alltid frusen, pekar på en fast källkod den byggdes från (stuvat tillsammans med utgåvan). Vi har inte för avsikt att ta bort någon tidigare publicerad version, så länge vår webbhotell leverantör (GitHub) förblir bra med att bevara dem för obestämd framtid, så du kan säkert rulla tillbaka till någon av dem utan att behöva göra självkopior.

Generellt sett när det gäller ASF-versionshantering, Vi gör vårt bästa för att följa semver version av MAJOR. INOR.PATCH på de 3 minst betydande talen - B.C.D. Dessa tre nummer är direkt relaterade till ASF:s kod. Det mest betydande A -numret indikerar förändringar med ett tillämpningsområde som sträcker sig bortom själva ASF-kodbasen, Vanligtvis direkt påverkar grunden för programmet.

ASF som ett projekt siktar på att ha mer eller mindre en funktion utgåva per månad, indikeras av en bula av C nummer. För att möjliggöra en sådan utgåva har vi mindre förhandsutgåvor tillägnad avancerade användare, som fungerar som mindre milstolpar av förändringar som släpps efter behov när det kommer att finnas tillräckligt med förändringar sedan den senaste pre-releasen för att fokusera på. Så småningom, när en slutlig förhandsutgåva kommer att vara tillräckligt stabil och mogen utan några kända kritiska regressioner som bör rättas till jämfört med tidigare stabila utgåvor, Det kommer att främjas till den nya stabila utgåvan, samtidigt som en ny månatlig cykel öppnas för nästa utgåva.

Medan vi gör vårt bästa för att se till att även våra pre-releaser är relativt stabila, det bör noteras att förutgåvor bör utvärderas noggrant när de körs i någon produktionsmiljö. Förutgåvor kan ha kritiska fel och annars trasig funktionalitet, vilket är exakt varför vi släpper dem till att börja med - så att vi kan undvika all den röra i våra stabila byggen och erbjuda tillförlitlig programvara. Om du är ovillig att acceptera ökad risk som kommer från att använda potentiellt instabil programvara, var snäll och undvik att använda våra pre-release-versioner och håll dig till vår senaste stabila utgåva istället, vilket är lämpligare för de flesta användare.

Beroende på antalet förändringar i cykeln, vanligtvis kommer det att finnas en enda C version bump (från tidigare stabila), och D gupp för varje pre-release efter behov. Men när förändringar införs med mycket större omfattning, särskilt bryta förändringar, cykeln kan starta från (eller växla i mitten till) B eller till och med A bump - sådan switch indikerar att nuvarande utgåvecykel har potential att vara mer instabil än vanligt, och bör testas noggrant. Tänk på att semver ändringar vi gör endast relaterar till tidigare släppta stabila versionen, vi spårar inte versionshantering över pre-releaser i en cykel själva, vilket innebär att version 1. .1.2 kan ha en ny funktion som 1.0.1. hade inte, så länge den tidigare markerade stabila utgåvan är från 1.0.0.X familjen. Likaså kan det finnas stora brytningsförändringar även över två pre-releaser från samma cykel, vilket är särskilt sant när vi fortfarande beslutar om den slutliga formen på nyinförda funktionalitet eller liknande.

Version bula	Semver	Exempel på ändringar
A		Major .NET runtime förändringar, fundament förändringar, bryta förändringar som är bortom ASF kodbas, saker som kan äta din katt
B	Större	Mindre .NET runtime ändringar, bryta förändringar i ASF codebase, större kodredigeringar som går utöver mindre klassificering
C	Mindre	Nya månatliga cykler, vanligtvis införa nya funktioner, kommandon, konfigurationsegenskaper eller andra förändringar som inte bryter befintliga installationer
D	Patch	Nya förhandsversioner som är en del av befintlig cykel (indikeras av mer betydande antal), kritiska buggfixar till befintliga stabila utgåvor som inte introducerar några kodändringar utöver nödvändigt

Observera att nyintroducerade funktioner och ändringar kan vara papperslösa (t.ex. på wikin) tills någon gång senare, eftersom dokumentation oftast skrivs när slutlig kod för given funktion är klar (för att spara tid skriva om dokumentation varje gång vi beslutar att ändra den funktion vi arbetar på). På grund av det faktum att pre-releaser kan innehålla work-in-progress kod som inte har ett slutligt formulär ännu, dokumentationen kan komma i senare skede av utvecklingen. Samma sak gäller för generell ändringslogg som kan vara otillgänglig för given pre-release fram till en tid senare. Om du därför bestämmer dig för att använda förhandsutgåvor så var förberedd för att titta inuti ASF binder då och då. Naturligtvis, brist på dokumentation gäller endast **** för förhandsutgåvor - varje stabil version måste alltid ha en komplett ändringslogg och dokumentation på wikin när den släpps.

Den exakta ändringsloggen som jämför en version med en annan finns alltid tillgänglig på GitHub - genom incheckningar och kodändringar. I utgivningen tenderar vi att dokumentera endast ändringar som vi anser är viktiga mellan den senaste stabila utgåvan och den aktuella utgåvan. En sådan kort ändringslogg är aldrig fullständig, så om du vill se varje förändring som hände mellan en version och en annan (såsom våra beroenden uppgraderingar) - använd GitHub jämförelse för det.

ASF-projektet drivs av vår kontinuerlig integrationsprocess. Varje byggnad är tänkt att vara reproducerbar, så det bör inte vara ett problem att ta tag i källa (ingår i utgåvan) av given version och kompilera dig själv få samma resultat som den som finns tillgänglig via våra förkompilerade binärer. Vi brukar undvika att sammanställa releaser själva, så länge systemen är operativa, de släppta binärer kommer direkt från vår CI-process.