Release cycle da DK

Udgivelsescyklus

ASF bruger fælles C # versionering med 4 tal, skrevet som A.B.C.D. Givet version er altid frosset, peger på en fast kildekode, det blev bygget fra (bundtet sammen med udgivelse). Vi har ikke til hensigt at fjerne nogen tidligere offentliggjort version, så længe vores hosting udbyder (GitHub) forbliver fint med at bevare dem på ubestemt tid, så du sikkert kan rulle tilbage til nogen af dem uden behov for at gøre selvkopiering.

Generelt med hensyn til ASF-version vi gør vores bedste for at følge semver versionering af MAJOR. INOR.PATCH på de 3 mindste signifikante tal - B.C.D. Disse tre tal er direkte relateret til ASF's kode. Det mest betydningsfulde A tal indikerer ændringer med et omfang, der går videre end ASF kodebase selv, som regel direkte påvirker grundlaget for programmet.

ASF som et projekt har til formål at have mere eller mindre én feature udgivelse pr. måned, angivet ved en bue på C nummer. For at gøre en sådan udgivelse mulig, har vi mindre præudgivelser dedikeret til avancerede brugere der tjener som mindre milepæle i ændringer, der frigives efter behov grundlag, når der vil være nok af ændringer siden den sidste pre-release til at fokusere på. Til sidst når en endelig præ-release vil blive bestemt til at være stabil og moden nok uden kendte kritiske regressioner, der bør korrigeres i forhold til tidligere stabil udgave, den vil blive forfremmet til den nye stabile udgivelse, samtidig med at der åbnes en ny månedlig cyklus for den næste.

Mens vi gør vores bedste for at sikre, at selv vores forhåndsudgivelser er relativt stabile, det skal bemærkes, at præudsætninger bør vurderes nøje ved kørsel i ethvert produktionsmiljø. Forudsætninger kan have kritiske fejl og ellers brudt funktionalitet, hvilket er præcis, hvorfor vi frigiver dem til at begynde med - så vi kan undgå alt det rod i vores stabile bygninger og tilbyde pålidelig software. Hvis du ikke er villig til at acceptere øget risiko, der kommer fra brug af potentielt ustabil software, skal du undgå at bruge vores pre-release builds og holde sig til vores seneste stabile build i stedet, som er mere passende for de fleste brugere.

Afhængigt af antallet af ændringer i cyklussen, vil der normalt være en enkelt C version bump (fra tidligere stabil) og D bump for hver pre-release på behørig basis. Men når der indføres ændringer med langt større rækkevidde, især bryde ændringer, cyklussen kan starte fra (eller skifte i midten til) B eller endda A bump - en sådan kontakt indikerer, at den aktuelle udløsningscyklus har potentiale til at være mere ustabil end normalt, og bør testes nøje. Husk, at semver ændringer, vi foretager, vedrører kun tidligere udgivet stabil version, vi ikke sporer versionering på tværs af præudgivelser i selve en cyklus, hvilket betyder, at version 1. .1.2 kan have en ny funktion, som 1.0.1. havde ikke, så længe den tidligere markerede stabile udgave er fra 1.0.0.X -familien. Ligeledes kunne der være store brydende ændringer selv på tværs af to præudgivelser fra samme cyklus, hvilket især gælder, når vi stadig beslutter om den endelige form af nyligt indført funktionalitet eller lignende.

Version bump	Semver	Eksempel på ændringer
A		Større .NET runtime ændringer, fundament ændringer, bryde ændringer, der er uden ASF's kodebase, ting, der kan spise din kat
B	Større	Mindre .NET runtime ændringer, bryde ændringer i ASF kodebase, store kode redigeringer, der går ud over mindre klassificering
C	Mindre	Nye månedlige cyklusser, normalt indføre nye funktionaliteter, kommandoer, konfigurationsegenskaber eller andre ændringer, der ikke bryder de eksisterende opsætninger
D	Rettelse	Nye præ-udgivelser, der er en del af eksisterende cyklus (angivet med mere betydeligt antal) kritiske fejlrettelser til eksisterende stabile udgivelser, der ikke indfører kodeændringer ud over nødvendigt

Bemærk venligst, at nyligt indførte funktioner og ændringer kan være udokumenterede (f.eks. på wiki) indtil et stykke tid senere da dokumentationen normalt er skrevet, når den endelige kode for den givne funktion er klar (for at spare os tid på at omskrive dokumentationen, hver gang vi beslutter at ændre den funktion, vi arbejder på i øjeblikket). Grundet det faktum, at forudgivelser kan indeholde work-in-progress kode, der ikke har en endelig form endnu, dokumentationen kan fremkomme på et senere stadium af udviklingen. Samme ting gælder for generelle changelog, der kan være utilgængelige for givne pre-release indtil et stykke tid senere. Derfor, hvis du beslutter dig for at bruge præ-udgivelser, så vær forberedt på at kigge inde i ASF commits fra tid til anden. Selvfølgelig manglende dokumentation gælder kun **** på præudgivelser - hver stabil version skal altid have en komplet changelog og dokumentation på wikien i det øjeblik, den bliver frigivet.

Den præcise changelog, der sammenligner en version med en anden, er altid tilgængelig på GitHub - gennem commits og kodeændringer. I udgivelsen har vi tendens til kun at dokumentere ændringer, vi anser for vigtige mellem sidste stabile og aktuelle udgivelse. En sådan kort changelog er aldrig en komplet en, så hvis du gerne vil se hver ændring, der skete mellem en version og en anden (såsom vores afhængigheder opgraderinger) - brug venligst GitHub sammenligning til det.

ASF-projektet drives af vores kontinuerlige integrationsproces. Hver bygning formodes at være reproducerbar så det bør ikke være et problem at få fat i kilden (inkluderet i udgivelsen) til den givne version og kompilere dig selv modtager det samme resultat som den, der er til rådighed via vores prækompilerede binære enheder. Vi undgår typisk selv at kompilere udgivelser, så længe systemerne er operative, kommer de frigivne binære filer direkte fra vores CI-proces.